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