[Jifty-commit] r876 - in jifty/trunk: doc

jifty-commit at lists.jifty.org jifty-commit at lists.jifty.org
Thu Apr 20 01:34:20 EDT 2006

Author: jesse
Date: Thu Apr 20 01:34:19 2006
New Revision: 876

   jifty/trunk/   (props changed)

 r11732 at hualien:  jesse | 2006-04-20 01:29:42 -0400
 Jesse and Audrey design session on client-side continuations

Added: jifty/trunk/doc/client_side_continuations
--- (empty file)
+++ jifty/trunk/doc/client_side_continuations	Thu Apr 20 01:34:19 2006
@@ -0,0 +1,129 @@
+01:01 <audreyt> I think DNS is your programming language of choice ;)
+01:01 <obra> *snicker*
+01:01 <obra> . o O {You must have seen the cname on quit.fsck.com }
+01:02 <audreyt> rofl
+01:02 <audreyt> mm, instead of passing cookies
+01:02 <audreyt> and maintain url transparency across post and get
+01:03 <audreyt> just pass the J:C and session token in DNS!]
+01:03 <obra> *groan*
+01:03 <audreyt> deadbeef18405930.hiveminder.com/
+01:03 <obra> alex and I were talking about client-side continuation serialization today
+01:03 <obra> We're about to do continuation garbage collection
+01:03 <audreyt> instead of passing it as part of request_uri
+01:03 <audreyt> in pathinfo
+01:04 <audreyt> this guarantees auth zone separation etc
+01:04 <audreyt> (very bad idea.)
+01:04 <obra> laugh
+01:04 <obra> definitely "Worst Impractical"
+01:04 <audreyt> this is not unlike .NET Passport
+01:05 <audreyt> where you visit something.microsoft.com that redispatch to your domain
+01:05 <audreyt> but there is a reason why it failed.
+01:05 <obra> *nod* OpenId seems to be doing a bit better at it
+01:05 <audreyt> right
+01:05 <audreyt> so, client side CC
+01:05 <audreyt> in hidden fields
+01:05 <obra> I worry about the amount of content you might need to pass around. and the fact that you lose GET support
+01:05 <audreyt> HMAC_SHA1 with server digest
+01:06 <audreyt> for small continuations (practically everything)
+01:06 <audreyt> you can embed it as part of pathuri
+01:06 <obra> except our continuations aren't that small. and when deeply nested you totally lose
+01:06 <audreyt> /=/deadbeefdeadbeefbeefbeef1982398102957190824091840984124/moose.html
+01:06 <audreyt> yeah. in which case you fallback to cookie storage.
+01:07 <obra> oh. you mean having a continuation id in the url and a cookie with the content?
+01:07 <audreyt> yeah
+01:07 <audreyt> the id is the cookie key
+01:07 <audreyt> you can have multipel cookies
+01:07 <audreyt> they can expire using normal cookie expiry semantics
+01:07 <obra> and then every GET or POST pushes all the cookies to the server
+01:07 <audreyt> not neccessarily
+01:08 <obra> using the path restriction in the cookie?
+01:08 <audreyt> the path component protects you
+01:08 <audreyt> the path component protects yothat's what cookies are for
+01:08 <audreyt> ys
+01:08 <obra> hm.
+01:08 <audreyt> self validating
+01:08 <audreyt> in a sense.
+01:08 <obra> you have a compelling argument, madam.
+01:08 <obra> hm
+01:08 <audreyt> I believe it's somewhat original
+01:08 <audreyt> or at least independent invention :)
+01:08 <obra> :)
+01:09 <obra> So. the first step is that alex is getting continuations into their own database table
+01:09 <obra> alex really wanted to sign them, rather than do digest validation
+01:09 <obra> because he wants _no_ server state for a continuation
+01:09 <audreyt> a private key is a state.
+01:09 <audreyt> same as a server secret.
+01:09 <obra> er. sorry. no unique state
+01:09 <audreyt> same.
+01:10 <audreyt> if you do HMAC_SHA1, only the server secret is required
+01:10 <audreyt> not nonce
+01:10 <audreyt> global shared secret
+01:10 <obra> ahhh.
+01:10 <audreyt> cheaper than signing.
+01:10 <obra> I missed that. sorry
+01:10 <audreyt> equally strong.
+01:10 <audreyt> np :)
+01:11 <obra> It's certainly an interesting argument for "how jifty can scale up"
+01:12 <obra> if we have the cookie and url scheme, is there a reason to complicate it with sometimes having hidden form fields?
+01:12 <audreyt> only if you want per-form, as in region, continuation
+01:13 <obra> regions have their own paths ;)
+01:13 <audreyt> good then
+01:14 <audreyt> so, cookie is specced to be min 4k
+01:14 <obra> I will admit that I get twitchy about how easily this is remotely 0wnable if you capture the server secret.
+01:14 <audreyt> and at least 20 per thing
+01:14 <audreyt> that gives 80k min storage
+01:14 <audreyt> in practice the 20 limit is not enforced
+01:14 <audreyt> so you get effectively unlimited storage with splitting
+01:15 <audreyt> I'll note that if you get server secret then you can set up fake forms.
+01:15 <audreyt> both requires owner permission on the share/
+01:16 <audreyt> and really there's little point in worrying at that stage.
+01:16 <obra> that also requires dHa willing dispatcher
+01:16 <obra> Alex's proposed attack was:
+01:16 <audreyt> nod.
+01:16 <obra> push a results message at the user containing "You must change your password. click here"
+01:16 <obra> phishing attack with a valid url
+01:17 <obra> I'd probably be mollified with a randomly generated session key 
+01:17 <obra> and actually have the session key stored server-side and ~nothing else
+01:18 <obra> (Does that make sense?)
+01:19 <audreyt> thinking
+01:19 <audreyt> how is it any different than the old cookie sessionid scheme?
+01:19 <audreyt> I mean the attack
+01:20 <audreyt> persumably the action will always need old passwd as input
+01:20 <audreyt> so it can't be automated
+01:21 <audreyt> I fail to see why client side state has anything to do with this.
+01:21 <obra> jifty action results contain messages.
+01:21 <obra> jifty apps display those messages
+01:21 <obra> the messages are defined to be able to contain html
+01:21 <audreyt> you mean rogue action classes?
+01:21 <obra> imagine an attack that pushes a mini form submitting to a third party into that html
+01:22 <obra> no, someone who redirects you back to hiveminder with a continuation constructed to make it appear that you needed to change your pw
+01:22 <audreyt> it is clearly result-message scrubbing thing...
+01:22 <audreyt> anyway. back
+01:22 <audreyt> if you want to have login/logout
+01:22 <audreyt> and continuations never work across logouts
+01:23 <audreyt> then the server secret is just the session id.
+01:23 <audreyt> i.e. nonce.
+01:23 <audreyt> which you don't give the user in entirety
+01:23 <audreyt> just as you observed
+01:23 <obra> nod
+01:23 <obra> I think that works
+01:23 <audreyt> and for public non-currentuser-related requests
+01:23 <audreyt> it may make sense to have a sessionless form
+01:24 <audreyt> where bookmarks may be shared.
+01:24 <obra> The case that didn't work in my head was with a global nonce.
+01:24 <audreyt> but I think the use case is rarer
+01:24 <audreyt> I think per-session makes most sense.
+01:24 <obra> indeed. It's been my conjecture that even anonymous users can be given sessions.
+01:24 <audreyt> if Inever logout, my bookmarks always work
+01:25 <audreyt> if I logout, they only work if I-or the server- explicitly requested affinity
+01:25 <obra> and the server has the option to deny that request 
+01:25 <audreyt> otherwise it's thrown away, and the logout link should reset the continuation cookies.
+01:25 <audreyt> yes.
+01:25 <audreyt> ok, very good design, I think.
+01:25 <obra> I'm reasonably happy with that, I think
+01:26 <audreyt> woot :)
+01:26 <audreyt> now I must run to $job
+01:26 <obra> shall we throw this log in jifty/doc?
+01:26 <audreyt> already horribly late ;)
+01:26 <audreyt> sure, please do
+01:26 <obra> oops. so sorry.

More information about the Jifty-commit mailing list