230698 - remote calendars use proxy, but don't prompt for proxy authentication

Status: RESOLVED DUPLICATE of bug 288313

(Calendar :: General, defect)

Description

[ken lierman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031217 Firebird/0.7+
Build Identifier: Mozilla Thunderbird 0.4 (20031205)

When configuring a remote calendar, it correctly goes to my configured proxy,
but does not prompt for the proxy's authentication info (username/password), so
i get an error screen and i can't get to remote calendars.

Reproducible: Always

Steps to Reproduce:
1. be behind an authenticating proxy
2. configure a remote calendar
3. sync the remote calendar
4. get an error saying the proxy authentication failed

Comment 1

[Emmanuel Blot]

It does not work when Calendar is used from Thunderbird (at least, Thunderbird 0.5).

However, the last release of Calendard works w/ proxy & authentication when used
from FireFox.

Does Thunderbird support HTTP(S) proxies ?

Comment 2

[ken lierman]

As a verification, it DOES work in firefox.  It didn't prompt me for my
password, so i assume it used the saved one.

SWEET!

I did update the calendar and publish it, but it didn't change on my ftp based
remote calenar.  Not sure if that's a limitation of using ftp and not webDav, or
something else.

Comment 3

[Flávio Henrique]

I have a similar problem, but without proxy server...
I did setup my webDAV server to require a specific user...

Using Sunbird 0.1.1+ no prompt is shown, when I try to insert a new Event or
when I try to publish the calendar...

Using DAV Explorer I got a prompt dialog for user/password

But I don't know, yet, if something is wrong in my webDAV server configuration,
because with DAV Explorer even typing the correct user/password I can't get
access to the directory.
But Sunbird should, at least, ask for a user/password login, right?

Maybe someone can confirm this or help me to find out some configurations
examples, because on webdav.org the help area is so simple.

Thank you

Hwoarang

Comment 4

[Martin Bagge / brother]

Please report back on this issue or mark it as WORKSFORME

Comment 5

[ken lierman]

I just reverified this on the latest loads. 

the standalone browser opens the remote file (correctly) in firefox, but doesn't
actually use any retrieved calendar data.  The calendar list spinny arrows just
spin forever.

For me, it now works correctly in the firefox plugin. (i'm using one of the most
recent 1.0PR nightlies).  By work correctly i mean it can fetch data from a
remote ftp site and use the calendar data.  It prompts for both the remote site
and proxy username/passwords. 

It does not seem to publish correctly to an ftp site.... i don't know if that's
normal behavior or not....

Comment 6

[Matthew (lilmatt) Willis]

Ken,
Would you (again) please try the newest builds and see if the bug continues to
appear?

Comment 7

[ken lierman]

(In reply to comment #6)
> Ken,
> Would you (again) please try the newest builds and see if the bug continues to
> appear?

state exactly the same as in my last post.  Just retested with standalone and
firefox extensions dated 11/12 (0.2a standalone, 0.8.1+ for firefox).

Can you clarify if it's *supposed* to be able to publish to an ftp server also,
or just webdav?

thanks!
ken

Comment 8

[Steven Novick]

The proxy authentication is an important feature that I would also like to see 
added.  I work behind a company firewall, but would like to access a remote 
(http) calendar.

Comment 9

[Steven Novick]

I just read another bug report and found this:

To get around the corporate firewall, add these lines to your prefs.js file 
(change myproxyserver/domain.pac to your proxy server):

user_pref("network.proxy.autoconfig_url", "http://myproxyserver/domain.pac");
user_pref("network.proxy.type", 2);

Comment 10

[Michael Hibbard]

*** Bug 281603 has been marked as a duplicate of this bug. ***

Comment 11

[Joey Minta]

I think bug 288313 pretty much fixes this problem.  As said in comment #9, the
mechanics for this have been there for awhile, now bug 288313 makes it easy for
users to find.  Reporter, do you have any objection to this being marked as a
duplicate of bug 288313?

Comment 12

[Simon Paquet [:sipaq]]

*** This bug has been marked as a duplicate of 288313 ***

Comment 13

[Reed Loden [:reed]]

The bugspam monkeys have been set free and are feeding on Calendar :: General. Be afraid for your sanity!