Closed Bug 249796 Opened 20 years ago Closed 18 years ago

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

Categories

(Calendar :: General, defect)

Product:
Calendar
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: npivic, Unassigned)

References

(
URL
)

Details

Attachments

(2 files)

missing values from chrome.rdf
516 bytes, text/plain
Details
screenshot-dvhart (ftp publish error)
51.47 KB, image/png
Details 
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: 20 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: 20 years ago → 18 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: