362088 - get_calprops is sometimes broken in Sun calendar server; leads to calendar hangs

Status: VERIFIED FIXED

(Calendar :: Provider: WCAP, defect)

Description

[Norbert Püschel]

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

I discovered that calendar server 6.2 has a problem with the get_calprop WCAP call. At least on our server, I always get WCAP error 28 (access denied), even though I'm logged on as owner of the calendar. This is not a lightning bug; I confirmed this speaking WCAP with the server using firefox. This might be related to bug 356125.

Reproducible: Always

Steps to Reproduce:
1. Login manually to Sun calendar server using firefox:
https://your.calendar.url/login.wcap?user=ME&password=SECRET&fmt-out=text/xml
2. Manual get_calprops FAILS:
https://your.calendar.url/get_calprops.wcap?id=SESSIONHANDLE&fmt-out=text%2Fxml
3. Manual search_calprops SUCCEEDS:
https://your.calendar.url/search_calprops.wcap?id=SESSIONHANDLE&calid=1&search-string=[e-mail]&fmt-out=text%2Fxml


Actual Results:  
get_calprops always fails with WCAP error 28, access denied
search_calprops succeeds

Expected Results:  
get_calprops should always succeed for owner

getCalProps_ should be modified to use search_calprops instead; alternatively,
it could try get_calprops and use search_calprops as an fallback.

Comment 1

[Norbert Püschel]

Attachment: This contains the patch for getCalProps_ to use search_calprops

Comment 2

[Max Spicer]

This is really a duplicate of #356125 but thanks for all the effort in solving it!

Comment 3

[Martin Schröder [:mschroeder]]

Marking DUPLICATE per comment#2

Comment 4

[Daniel Boelzle [:dbo]]

Norbert, I have had a look at using search_calprops instead of get_calprops and it seems to have a limitation: search_calprops doesn't find secondary calendars, e.g. "user:myHolidyCal". This hinders getting calprops for all subscribed calendars which is an upcoming feature.
In bug 366441, it was mentioned that there weren't any problems with a get_calprops on a 116577-24 patched server. Are you sure, your server is patched properly?

Comment 5

[Norbert Püschel]

Daniel, at least this is what I get on our server:

bash-3.00# showrev -p | grep 116577-24
Patch: 116577-24 Obsoletes: 117706-08 Requires:  Incompatibles:  Packages: SUNWics5, SUNWica5

Maybe it is not only a matter of patch level but of configuration. But I could not find any configuration setting that seems to be related to this problem.

I haven't tried out secondary calendars yet. I will check this; maybe it is a matter of what search condition is used with search_calprops.

Comment 6

[Norbert Püschel]

OK, I have researched the matter and have a new version of the patch that will use search_calprops in a way to return the properties of all calendars owned by the current user, which will give you the mentioned user:myHolidayCal.

It won't give you calendars owned by other users that you subscribe to. I don't know if get_calprops would return these and can't check it, as get_calprops doesn't work on my WCAP-server.

Please note that this change currently can trigger bugs. I just created a secondary calendar for testing and found that search_calprops returns its properties before the properties of my primary calendar, which changed the displayname to the name of the secondary calendar while displaying the events of the primary calendar. There still seems a lot of work to be done for multiple calendar handling...

Revised patch follows.

Comment 7

[Norbert Püschel]

Attachment: This is the revised patch for getCalProps_ to use search_calprops.

Please note this patch may have unexpected results when you actually have more than one calendar on the server, as Lightning seems not yet to be ready to handle this correctly.

Comment 8

[Daniel Boelzle [:dbo]]

Some comments on the patch:
- please use "&searchOpts=1" searching for the exact string
- use "&calid=1" instead of searching the primary owners. What we really search for are calprops for a specific calid.

Comment 9

[Max Spicer]

Making this the open bug and marking bug 356125 a duplicate of this one.  This is where the work's going on, so it's pointless marking this bug as the duplicate.

Comment 11

[Daniel Boelzle [:dbo]]

The current provider uses get_calprops by default, but offers a pref to use search_calprops: calendar.wcap.no_get_calprops -> true. See also <http://wiki.mozilla.org/Calendar:WCAP_Provider#Trouble_Shooting>.