Question about privileges & tickets

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
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

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
> Cosmoosafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo

_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo

On 2/15/06, Lisa Dusseault <lisaosafoundation.org>
wrote:
> 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.

for what it's worth, if you provide basic credentials to
cosmo, then
the ticketdiscovery property will contain all tickets owned
by that
principal. one use case where this might not be the full set
is if an
administrator for some reason creates a ticket on a resource
in a
user's home directory.

without thinking through the issue in detail, i agree with
lisa that
it doesn't make sense to share the existence of other
tickets on a
resource with a person who knows only of one ticket.

i could certainly extend the current functionality so that
if the
authentication credential is a ticket id, the
ticketdiscovery property
returns the details for that ticket only. indeed, i've
opened an
enhancement request for this
(<https://bugzilla.osafoundation.org/show_bug.cgi?id=52
00>).

> 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.

what do you mean by "what they were good for"?

anyway, i think that cosmo, behaving as described in bug
5200, does
basically the same thing for ticketdiscovery as acl defines
for
current-user-privilege-set, except it only does it for the
one ticket
that is verified as the authentication credential.

i suppose we could add to bug 5200 to have one ticketinfo in
the
ticketdiscovery for each ticket id provided in the request.
i think i
like that better than inventing another ticket property.
_______________________________________________
Cosmo mailing list
Cosmoosafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo