371753 - Url Authentication

Status: RESOLVED DUPLICATE of bug 247486

(Calendar :: Sunbird Only, defect)

Description

[lionel valero]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070226 

sunbird nightly build, and 0.3.1 as well

I have a caldav server : rscds 0.6.0

I have 3 calendars :

-1 : url=https://lionel:my_pwd@x.x.x.x:yy/caldav.php/gchsi/
-2 : url=https://lionel:my_pwd@x.x.x.x:yy/caldav.php/c_lvalero/
-3 : url=https://sarah:her_pwd@x.x.x.x:yy/caldav.php/c_sarah/

--> calendar 1 and 2 have the same (user,pwd).

1/ I subscribe to calendar 1, sunbird do not ask for authentication as expected.

2/ I subscribe to calendar 2, sunbird ask for authentication, it is not expected.

3/ I subscribe to calendar 3, sunbird do not ask for authentication for the calendar 3 but still for the calendar 2

4/ delete subscription to calendar 2, close sunbird

5/ resubscribe to calendar 2, sunbird do not ask for authentication anymore.




Reproducible: Always

Comment 1

[Bruno Browning]

This looks to me like a duplicate of bug 361688 and if so it's not a mozilla bug so much as an attempt to use rscds for something it wasn't designed for. Reporter, is there some reason you believe the two are different?

Adding the author of rscds to the cc list in case he's added new functionality to it since 361688, such that this password behavior is now unexpected.

Comment 2

[Andrew McMillan]

Thanks Bruno,

To me, it seems that if you are accessing multiple URLs from the same realm then you should be expecting to use the same credentials for them.  The CalDAV server should (and can) provide support for permissions to access calendars for other people/resources within that realm.

In the case above, you would be accessing Sarah's calendar as Lionel, with whatever server-side-defined permissions Lionel has to alter Sarah's calendar (possibly full rights).

This is something of a special case, because the username/password are encoded in the URL, but what Mozilla does to handle storage of those details is presumably not simply by storing the URL - for security reasons if nothing else.

Cheers,
Andrew.

Comment 3

[Bruno Browning]

Lionel, on rereading the bug I wonder if the issue here is not simply doing everything from the same machine. Once you've authenticated to that realm as lionel you're not going to be prompted for sarah's credentials, simply because you're already authenticated to that realm with that instance of Sunbird. I think that if you authenticate from one machine as lionel and another as sarah, you'll see the behavior you want and expect. As Andrew points out, you can then rely on RSCDS's internal access controls for calendar permissions.

Comment 4

[cmtalbert]

To Bruno, Andrew, or Lionel: What is the status of this bug? It seems that the issue is understood and resolved as "not a bug".  Can we mark this as INVALID then?  Or is there some reason for keeping it open?

Thanks.

Comment 5

[Bas van den Bosch]

see also bug 247486 regarding the realms...

Comment 6

[Bruno Browning]

(In reply to comment #4)

I don't see any reason to keep it open, so I'm going to close it INVALID. Lionel, if you disagree please reopen with some comments as to why.

----> INVALID

Comment 7

[lionel valero]

Hello,

I assume it is a bug because at the end it works, if you look at points 4 and 5 in the first post, sunbird's behaviour has changed, and does not ask for authentication anymore.

Regards.

Comment 8

[cmtalbert]

Lionel, can you explain why you feel that this is not a the same issue that is reported in bug 247486?  To me, it sounds like the same sort of issue is at work here.

Thanks.

>> dupe 247486??

Comment 9

[Steve]

Just a post to confirm that I have experienced a similar problem as recent as the 5/02/07 nightly build of pre-0.5 for Windows.  In my case, I was attempting to use five calendars on the same server with the same credentials sent via http.

Example:
http://myuser:[e-mail]/cal/calname.ics
http://myuser:[e-mail]/cal/calname2.ics
http://myuser:[e-mail]/cal/calname3.ics
http://myuser:[e-mail]/cal/calname4.ics
http://myuser:[e-mail]/cal/calname5.ics

The username/password was identical for each/all of them.  Sunbird has quirky behavior with this.  Some of them will work fine, and some will pop up the window asking for the password.  Even if the username/password is saved, it will still ask when doing a manual calendar reload or on starting the program.  It is almost random, however, because if I unsubscribe to a calendar and then add a new subscription, it will pop up the password thing on another one.

I should add, however, that in this same version, I have tested the url's without sending the user/pass in the url, but using Sunbird's password remember feature.  It is working on two machines subscribed to six calendars each on the same server with the same user credentials.

I had tried to use the user/pwd in the http with previous builds b/c Sunbird wouldn't remember the user/pass information consistently.  That seems to be resolved now.  It might be best to put this in the doc's somewhere as a known issue with sufficient work-arounds.  It's probably safer for sunbird to store the passwords anyway, than they be in the url.

I will make the same post over at bug 247486.

Steve