[Cosmo] Question about privileges & tickets

[Lisa Dusseault]

I'd say that that should only be allowed to work if the client  
provides the ticket and the URL (of course in the Request URI), and  
if those in fact match up, then the server provides information on  
that particular ticket.  We don't want to open up for abuse of  
finding previously unknown tickets obviously.

But this might not be a property any more, or at least it might be a  
different property.  The closest similarity is to the "current-user- 
privilege-set" calculated property defined in ACL (RFC3744), which  
returns the privileges of the current user.  If we modeled a solution  
after that we'd have a 'ticket-info' property which, for the ticket 
(s) provided in the Ticket header, returned what they were good for.

I think this is a reasonable addition to the ticket draft.

lisa


On Feb 15, 2006, at 3:42 PM, Grant Baillie wrote:

> One issue we've been having with Chandler and tickets is that it's  
> hard to determine what  privileges you've been granted with a ticket.
>
> Especially once we have/are using <CalDAV:view-free-busy> tickets,  
> it would be nice to be able to tell what privileges a ticket gives  
> you: This way, clients can tell what kind of REPORT to issue (or,  
> for offline clients, like Chandler, whether or not to GET all the  
> events).
>
> My hope was to be able to use the <ticketdiscovery> property for  
> this. In other words, if a client issues a <ticketdiscovery>  
> PROPFIND request that's authorized via a ticket, servers would be  
> required to include <ticketinfo> for that ticket in the response.  
> Sadly, this doesn't seem to work with either xythos or cosmo, and  
> is also not required by the ticket internet draft.
>
> Does this sound like a reasonable feature request for cosmo (and/or  
> future revisions of the ticket draft, if that moves forward)?
>
> --Grant
>
> [FWIW, Chandler currently only deals with <DAV:read> and  
> <DAV:write> tickets, so Chandler is able to tell whether you have  
> write access via a somewhat cheesy manoeuvre that works for cosmo:  
> We MKCOL a collection underneath your calendar collection, see  
> whether that succeeds, and then DELETE it. This is the underlying  
> reason why subscribing to an Oracle server's CalDAV calendar gives  
> you a read-only share in Chandler].
>
>
>
> _______________________________________________
> Cosmo mailing list
> Cosmo at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo