361688 - Authentication multiple users multiple calendars on the same server

Status: RESOLVED INVALID

(Calendar :: Provider: CalDAV, defect)

Description

[lionel valero]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

I have a caldav server and the calendars urls are like that :

https://xxx.xxx.xxx.xxx:8080/caldav.php/<CALENDAR_NAME>

I have 2 calendars and one user per calendar which can modify it :

https://xxx.xxx.xxx.xxx:8080/caldav.php/si  --> user:si,password:xxx
https://xxx.xxx.xxx.xxx:8080/caldav.php/gchsi  --> user:gchsi,password:xxx

When i subscribe to both calendars under the same client (Lightning 0.3, Sunbird 0.3 and Sunbird nightly build) the client mixed up between users and calendars, it seems that it cannot match the good user to the good url/calendar.

When subscribing to the second calendar, the server do not ask for an authentication, maybe because it got already a successfull authentication from the first subscribed calendar.

I can not figured out if it is a client or server issue.

regards.

Reproducible: Always

Comment 1

[Bruno Browning]

It would be helpful if you could specify what CalDAV server you are using. 

From the looks of your calendar URIs, it appears likely that they are in the same http authentication realm, which would explain why you do not get a separate password prompt. But that's a server issue rather than a Sunbird one.

Comment 2

[lionel valero]

Hello,

I use this one :
http://rscds.sourceforge.net/index.php

Regards.

Comment 3

[Andrew McMillan]

Yeah, RSCDS will use the same authentication realm for any given installation, which does not seem unreasonable.

Most use cases for RSCDS that I can think of involve one person subscribing to multiple user calendars and using the same authentication credentials for all of them.

So it seems to me that this bug is invalid.

Comment 4

[Bruno Browning]

This bug describes a server-side problem (inappropriate access granted) rather than a mozilla calendar problem.

The server author states that this CalDAV server does not support the expected functionality.

Therefore this bug is INVALID