[cosmo-dev] options to fix security hole

[Randy Letness]

Mimi Yin wrote:
> + What about the case where Randy receives item 1 via both collections 
> A and B?
> - Randy was granted read-write access to collection A and read-only 
> access to collection B.
> - The client needs to logic to know to give Randy read-write access.

This should work because when the client updates collection A it will be 
updated in B because of the item soup, although B is read-only.  If the 
client tries to update B, the server will fail silently to keep existing 
clients working.


> + The same is true if Randy create collection B. Another subscriber or 
> Randy creates item 1. Then that subscriber adds item 1 to collection A 
> and shares A with Randy with a read-only ticket. Randy should still 
> have read-write access to item 1.

I think this is the same as above because the item was originally 
created in B read-write.  Unless for the desktop, read-only wins,  I'm 
not sure what the desktop does in this case.


> + However, if Randy receives item 1 via a read-only ticket for 
> collection A and then adds item 1 to collection C which he has 
> read-write access to it, read-only wins and he shouldn't be able to 
> edit item 1.

Right, this his how it would work.


> Jeffrey does what you're describing below mean that if you receive an 
> item only via Email and then you publish it the server, you won't be 
> able to edit anymore? Or could we still do some selective silo-ing on 
> the server to prevent that from happening?
>

That is correct.  There would be no silo-ing and the server would see 
the uuid exists and add that item read-only when you publish it because 
it already exists.  If this isn't desirable, maybe we could modify the 
emailed item to have a different uuid or modify the client to create a 
new uuid if one doesn't exist in the repository.

-Randy