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

Brian Moseley bcm at osafoundation.org
Fri Sep 28 16:11:34 PDT 2007


On 9/28/07, Morgen Sagen <morgen at osafoundation.org> wrote:

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

i think we should be designing the server and the protocol to lock
down access to items as tightly as possible. among other things, i
think that means the permissions on the source collection are more
important than the permissions on other collections an item
incidentally happens to be a member of, and that those source
permissions should move with the item when it's copied into a
destination collection. this "deny, then allow" policy is more
conservative and, i think, safer than the opposite.

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

that is technically true. it seems to me that there's a problem in the
mental model of how the user has organized his data if he has put an
item in two collections and given the same collaborator read-only
access to one collection and read-write access to another. there is a
flexibility versus security trade-off, and i'd prefer to err on the
side of security. but maybe i haven't been presented with a compelling
scenario that makes this all seem reasonable.

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

good point.

you didn't address my point about having my eim processor independent
of my protocol handler. would it be reasonable to find a way to
specify tickets in the eim recordset collection, not in the request
headers (either as part of the entire eim collection, as per your
suggestion, or with each individual recordset, as per mine)? they
could be specified as (ticket-key, collection-uuid} pairs rather than
urls.


More information about the cosmo-dev mailing list