On 8/21/06, Mimi Yin <[EMAIL PROTECTED]> wrote:

To clarify again. would it be fair to say that an URL that does not
include a ticket IS more hackable if the sharer does NOT password
protect the share.

no, because nobody would be able to access the url except the sharer,
who can present his cosmo username and password.

unless the user includes *some* sort of credential - a ticket, or a
username and password - the url is not accessible.

What if the user doesn't want to password protect the share?

then they get the default read-only and read-write tickets, just like today.

or do you mean, what if the user wants the share to be public? hm.
we'd have to figure out a way for the sharing process to communicate
that to cosmo, and we'd have to add the notion of "public" to cosmo's
security model. this is where we start to get into acl land.

Are you saying the 2 options should be:
+ Provide a URL (with embedded ticket) OR
+ Provide a URL (without embedded ticket) + password?

sort of. what i'm really saying is:

+ provide a url with an embedded ticket chosen by the user (like your
password suggestion) OR
+ provide a url with an embedded ticket chosen by the server (like today)

that way the server always has a ticket with associated privileges,
but the ticket string can either be something random or something
memorable.

The only scenario where I think this would be a problem is if I
wanted to turn off password protection, I would need to send out a
new URL. But maybe we don't care about that.

right, you'd need to delete the old ticket (the one chosen by the
user) and have the server generate a new one, or make the collection
public (if we decide to go that far).

What's the problem you see with having both an URL (with embedded
ticket) + a password?

the problem is that the server's security model and implementation are
more complicated with your original proposal. with mine, they're much
simpler, and the implementation is correspondingly simpler, with a
cleaner design.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Reply via email to