[Cosmo-dev] Re: securing access to items in multiple collections

Morgen Sagen morgen at osafoundation.org
Fri Sep 28 15:09:35 PDT 2007

On 9/28/07, Brian Moseley <bcm at osafoundation.org> wrote:
> On 9/28/07, Morgen Sagen <morgen at osafoundation.org> wrote:
> > - There are two collections on the server: A, B
> > - An Item is in A
> > - I am subscribed read-only to A, and read-write to B
> > - In my client I copy the item from A to B
> > - When I sync B I include in the HTTP headers the ticket-URLs for A
> > and B (all collections I am subscribed to via ticket on this server)
> > - Cosmo looks to see if the item exists on the server, and seeing that
> > the item is in A examines the request headers for URLs matching
> > collection A
> > - Cosmo sees if that ticket for A is read-write, and since it isn't it
> > rejects the request
> i don't want to check access based on the happy accident that an item
> happens to be a member of a particular collection *and* you've told me
> that you have a ticket for that collection. that doesn't tell me
> anything about the specific collection you copied the item from.

I guess I don't see why it matters which collection you copied the
item from, and so I feel like this may be why we're not coming to
agreement on the proposals.  See below.

> i think permissions should be based on the specific collection in
> which you're interacting with an item, or in the case of republishing
> a copied item, the specific source collection.
> imagine an item that is a member of both of two subscribed collections
> A and B. you have a read-only ticket for A and a read-write ticket for
> B. you make a local collection C and drag the item from A to C. then
> you publish C. which ticket should be examined - the A ticket or the B
> ticket?

Both, since the item is in both A and B.

> with your proposal, the server would see that you've included ticket
> urls for both collections A and B in the request, and it would have to
> make a choice about which one it wants to use. you might argue that it
> should choose the most tightly restrictive one,

No, I would argue that if *any* of the matching ticket-URLs grant
read-write access, the request should succeed.  If the server only
used the most tightly restrictive one, the client could instead just
*not* include the read-only ticket and thereby get read-write access

> and that would work
> out fine for my example above, but it wouldn't work if you had tried
> to copy an item from collection B to C, because the most tightly
> restrictive ticket, the read-only one for A, would deny the publish. i
> can't think of any other rule that wouldn't cause a similar problem.

Right, I'm not suggesting a "most tightly restrictive" algorithm,
rather the opposite.

> with my proposal, the server only has to check one ticket against one
> collection - the source collection - so it never has to make any such
> decision.

What are we trying to solve with tracking which collection a
republished item was copied from?  In the scenario where the client
copied from A to C, you're saying that should fail, but copying from B
to C should succeed (correct me if I am misunderstanding this).  Why
shouldn't that succeed in either case?  If we cause the A to C copy to
fail, the user is going to try again by copying from B to C.  Simply
put, the user has write access to the item because they can just go
edit/sync the copy in B.  I must be missing something crucial here
because I don't yet see the importance of tracking the source

> another benefit is that the credential, which is only valid in the
> scope of a single item, is bundled inside the request payload with the
> recordset for that item, so that the recordset can be processed by a
> layer that is independent of the protocol processing layer.
> it also removes any need to send tickets for published collections,
> which is just plain wrong. a ticket is not a mechanism by which a
> known user expresses to the server that he has permission to take an
> action. tickets are only for anonymous access.

I agree sending the ticketed url for a published collection is
strange, but how else would someone ever copy an item from one of
their own collections to a collection they subscribe to?  When the
client syncs that other collection they're not using basic auth, just
the ticket for that other collection, so there would need to be some
way to let the server know that the client does have write permission
for the item.

> (here is where i make a tangential claim)

I am in complete agreement with you on moving forward with real access control.


More information about the cosmo-dev mailing list