Closed Bug 249796 Opened 21 years ago Closed 19 years ago

I am unable to configure user/password when wanting to publish my calendar to a remote location

Categories

(Calendar :: General, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: npivic, Unassigned)

References

()

Details

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8 I am using Mozilla Sunbird, the stand-alone edition, the build is the latest nightly. I am not able to publish my calendar, or any calendar, to the location which is specified in the file above (see the URL-part, where an animated GIF shows the problem). I have used another program, Windates (http://www.rockinsoftware.com/WinDates.aspx) to replicate the problem, and it works perfectly, as I am able to enter a username and password. Reproducible: Always Steps to Reproduce: 1. I start Mozilla Sunbird. 2. I try to publish any calendar I may have, in the ways I know (both displayed in the animated GIF shown above, in the URL-part). 3. When clicking the "Publish" button, I immediately get a "Close" button without there being anything working in the progress bar. Actual Results: Absolutely nothing. Expected Results: Published my calendar/event to the provided location. I find this behaviour to be similar to bug #180970, yet mine applies to the Windows platform and is a bit different.
This seems to be a bug in mozilla trunk code. If you copy the attached file to <your profile dir>/chrome it should work.
Thanks, Mostafa. That certainly did the trick. Now a window requiring a user name and password pops up when I opt to publish my calendar.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
This isn't really fixed. Still would happen on a new build
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
To me, as a user, this sounds absolutely unthinkable; I'm happy with this little special solution which helps me, but if I hadn't submitted the bug, are you implying I would never be able to publish a calendar to a WebDAV server that demands a username and password? I'm thinking of the other users, here.
That is why i said this bug isn't fixed. It works for you now, but not for other users. We need a better solution, one that works for everybody.
This might very well be fixed by the patch for bug 251213.
I have been reading this thread and it's related now, due to the fact that I stumbled across this problem myself right now. However, the patch didn't work for me. I am running TB 0.7.3 (20040803), with the calendar extension: Mozilla Calendar 2004080310-cal. I am using private, shared calendars via icalx.com. I have set up the above on one computer where everything just works. This is my own computer where I installed the first Moz stuff probably about 6-8 months ago. This computer runs WinXP. BTW: This computer also have FF 0.9 installed. On the seconds computer I have installed the same packages as above, except for FF. In addition this computer had no Moz stuff until a couple of months ago. OS is Win2K. I have desperately tried to make the calendar extension accept a remote calendar, without luck. Whenever I publish or subscribe I never get a prompt asking for user/password. The "load" indicator behind the calendar name just keeps spinning. (The very same shared calendars work on the XP box). I tried to add the patch here, but it didn't work. I added the stuff to the chrome.rdf file that was located in the profile directory for the logged on user (correct?). Now I have tried "everything". I have read the FAQs, searched bugzilla, applied the given patch, read the main forum entries. So I am just about to give up now. This bug-entry was the closest I could find. Hope that you guys can shed some light on this.
*** Bug 255904 has been marked as a duplicate of this bug. ***
*** Bug 256215 has been marked as a duplicate of this bug. ***
*** Bug 255903 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > This might very well be fixed by the patch for bug 251213. Confirming this bug based on dupes. Mvl, it seems that the patch in bug 251213 did not fix this issue. This is a serious issue with a high visibility.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 253567 has been marked as a duplicate of this bug. ***
bug 253567 looks like the only real dup so far to me. And that is about an old build. So it might still be fixed.
Tested again on most recent build (Sept 7, 2004) running on Windows XP SP2, using the installer on empty directories, still fails. Tried the recommended modification to the profile chrome.rdf file, to no avail. This is a show stopper for our usage, unfortunately.
What is the version of calendar, from help->about calendar? something like mozilla calendar 2004xxxxxx-cal
If this is still failing for anyone, it would be good to have the url to the remote calendar ( user /pass not needed ). If not please try this url to see if you get the SSL dialog window: https://boolean.is-a-geek.net/mydisk/mostafah/Calendars/Personal.ics mvl: Should bug 256612 be resolved as a duplicate of this one?
This morning, after a reboot, but no other changes, tested above URL and to my surprise was greeted with a username/password prompt. Tried my own URL and saw that it worked as well. I can't imagine why a reboot would make any difference -- sorry for the confusion. Changes I make don't seem to be saved to the server (after publish, refresh removes the new items), but I expect that is a permissions promblem on my server rather than a Sunbird error (unless others are finding the same thing). Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040907 Mozilla Sunbird/0.2a
I am still having this issue. I did add the two XML elements listed in the first reply to both C:\Documents and Settings\mpullen\Application Data\Thunderbird\Profiles\32y9c8ky.default\chrome\chrome.rdf and C:\Program Files\Mozilla Thunderbird\chrome\chrome.rdf I also rebooted. I still get no dialog asking for username and password for your calendar or my own. Interestingly, I do get the dialog from my WinXP system, just not the Win2k machines. Mozilla Calendar 2004091012-cal Mozilla/5.0 (Windows; U; Windows NT 5.0; rv: 1.7.3) Gecko/20040913 Thunderbird/0.8
I have also tried using a url of type: http://username:password@url since I don't have access to the pop-up dialog, this also doesn't appear to work ( the progress indicator arrows just spin). This does successfully log me in and let me see the ics file from a browser. There aren't many people posting here, or voting for this defect, but a couple quick searches grough groups.google will show that this has hit MANY people.
This bug is still present in Mozilla 1.8a4 w/ the 2004091012 build of Calendar, modfications listed in the first report don't help and this is also a show stopper for us.
All: One thing that might be causing this is that you are behind a proxy. It maybe that the application you are using doesn't have proper proxy settings or like in sunbird's case cannot set any proxy settings. One way to work around this problem is to manually copy over the proxy settings from a working app ( e.g. firefox ) to your profile.
Solved (in my case). What makes this nasty, is that it has a couple issues that are somewhat common, that all have the same result. First, I did this on xp and win2k machines, from home and work. All machines had the spinning progress meter. I edited the chrome.pdf files (both in my profile and the product in general). This solved the XP problem, which was being run from home. The windows 2k boxes had to be restarted, then they worked as well ( from home ). The box at work still had the same issue, even though identical fixes had been perfomed on it. It turns out that I am behind a proxy at work, and since I was using webdav, I had to manually copy the settings from my firefox prefs.js to my thunderbird prefs.js ex: user_pref("network.proxy.autoconfig_url", "http://myproxyserver/domain.pac"); user_pref("network.proxy.type", 2); It now works on all boxes I have tried. Cheers and good work Mostafa Matthew
No proxy in use here - Win2k/WinXP/OSX workstations on the same subnet as the server. If I use a publish location that doesn't require username/password it works fine, but that's not suitable for our environment.
Craig: do you get any error or something? what is the url you are publishing to? It might be that the server doesn't reply with 'password needed', but with 'access denied', and mozilla doesn't try again. Depends on the type of server, and the access rights. A network strace using http://liveheaders.mozdev.org/ or some packet sniffer might give clues on what's going on. (not sure if liveheaders works with calendar, it certainly wont with sunbird)
I just get the spinning wheel within calendar. This is publishing to a WebDAV share - loading the same url in a browser works as I get prompted for a username/password. On the same server, different location, that isn't password protected but is read/write for all works without issue. So, it is the lack of username/password that seems to stuff things. I'll try to get a decent network trace tomorrow - I grabbed a few other tools to trace traffic before even reporting the problem, but couldn't get a clean grab. I've moved the server and clients to a test network now.
I was finally able to test this some more. I think my problem is actually two issues: 1) Our Apache setup was configured with "SSLVerifyClient require" - we're required to demand a client certificate on our web servers. Setting this to "SSLVerifyClient none" for the WebDAV share seems to fix this. I'm going to look for some help on this from the mod_dav/mod_ssl folks. 2) If I tried to create a new calendar file that is to be published at a remote location, and the file didn't already exist - then I'd get an error. I expected Mozilla to create an empty calendar file for me. If I place an empty file, I get an error about this not being a valid calendar file - I can understand that. If I create an empty calendar, which is a valid ics file, and put it in the right place it starts to work. So, do I need to pre-create empty calendars for all of my users or should the calendar extension make one for me when setting up a new calendar ? The New Calendar dialog still doesn't contain a username/password prompt, but it now prompts me for my username/password when I found out about #1. Thanks and sorry for the confusion, Craig
Does not work for me w/ firefox extension either, I have Webdav over HTTP or HTTPs, no password/username fields present on Linux or XP.
I too am having this issue, with Sunbird - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041112 Mozilla Sunbird/0.2b I'm running FF 1 and TB 1. Trying to do FTP upload / synching with no luck. No name and password boxes. If I embed the name and password in the url it won't work, but on cancel the file loads in FF just fine... This is all on Windows XP Pro. I tried putting the RDF patch in, in both the chrome.rdf in the sunbird folder, and in my profile folder, with no luck.
I'm having this trouble too. Running calendar_windows_20041217 as extension to Thunderbird 1.0 on XP. Also tried it on Win2K with T-bird 1.0. Tried the fixes here, adding the "missing values" attachment to every chrome.rdf file I could find on my system. I get no username/password fields, so I can't publish my calendar. This would be a really cool app, but without publishing it's generally useless to me.
I am still seeing this bug as well. I am using Thunderbird 1.0 and the Calendar extension 2005011113-cal on Linux. I am trying to publish to an FTP location. When I try to publish I just get an error message (see screenshot-dvhart above). I get this regardless of whether I add the username:password to the URL or not.
Interestingly enough, Sunbird 0.2 seems to work fine with this URL if I specify the username:password in the URL.
Strangely enough build 2005011113-cal for Firefox is able to read from and publish to a ftp URL with the username:password syntax as well, so only the Thunderbird extension seems to fail. I tried the thunderbird extensions with and without my gnome-fx theme, both failed. The firefox extension seems to ignore the firefox theme and use the default calendar icons and such - not sure if that is relevant.
thunderbird doesn't include the ftp protocol.
(In reply to comment #35) > thunderbird doesn't include the ftp protocol. ...which is bug 253567 (wrongly, IMO, marked as a duplicate of this one).
*** Bug 255853 has been marked as a duplicate of this bug. ***
QA Contact: gurganbl → general
Reassigning all automatically assigned bugs from Mostafa to nobody@m.o Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
What's the status of this bug? Has anyone still had this problem with 0.3a2?
I have tested publishing to a secure WebDAV folder and to ftp addresses. In both cases, I get a password dialog. I also get the mentioned ssl cert dialog. ftp does not work with Thunderbird/Lightning which is known. There could be an error dialog explaining the issue. (Currently it endlessly tries to publish until the user decides to abort). One remaining issue that I have encountered is using the ftp address without specifying username (ftp://server/File.ics instead of ftp://user@server/File.ics) In this case, Sunbird assumes anonymous login, which is hardly ever with write access. An improvement would be to ask for username/password if anonymous publish fails. The second remaining issue is regarding comment 27, where "SSLVerifyClient require" was set. I tried this (without installing a client certificate) and Sunbird/Lightning do not give an error message leaving the user in the dream that publish has been successful! There is a Javascript error: Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.requestSucceeded]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: chrome://calendar/content/publish.js :: anonymous :: line 265" data: no] Source File: chrome://calendar/content/publish.js Line: 265 (Firefox does answer with an error dialog if one tries to access the same share) tested using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061105 Calendar/0.4a1. and Lightning 2006110511/Thunderbird version 2 beta 1 (20061102)
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061127 Calendar/0.4a1
(In reply to comment #40) > I have tested publishing to a secure WebDAV folder and to ftp addresses. In > both cases, I get a password dialog. I also get the mentioned ssl cert dialog. > ftp does not work with Thunderbird/Lightning which is known. There could be an > error dialog explaining the issue. (Currently it endlessly tries to publish > until the user decides to abort). this is handled in bug 273476 > One remaining issue that I have encountered is using the ftp address without > specifying username (ftp://server/File.ics instead of > ftp://user@server/File.ics) > In this case, Sunbird assumes anonymous login, which is hardly ever with write > access. An improvement would be to ask for username/password if anonymous > publish fails. this is handled in bug 273478 > > The second remaining issue is regarding comment 27, where "SSLVerifyClient > require" was set. I tried this (without installing a client certificate) and > Sunbird/Lightning do not give an error message leaving the user in the dream > that publish has been successful! There is a Javascript error: > > Error: [Exception... "Component returned failure code: 0x80040111 > (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.requestSucceeded]" nsresult: > "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: > chrome://calendar/content/publish.js :: anonymous :: line 265" data: no] > Source File: chrome://calendar/content/publish.js > Line: 265 > > (Firefox does answer with an error dialog if one tries to access the same > share) > this will be filed as a follow up bug: bug 363085 I will resolve this bug as WFM.
Status: NEW → RESOLVED
Closed: 21 years ago19 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: