perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Ihnen <dav...@norchemlab.com>
Subject Re: preserving request body across redirects
Date Tue, 30 Dec 2008 20:47:21 GMT
Mark Hedges wrote:
> On Tue, 30 Dec 2008, David Ihnen wrote:
>   
>> in the meantime server 556 dublin suffered a network
>> connector air gap issue.  A trouble ticket has been
>> created.  These things happen.
>>
>> client -> GET <success bounceback url> -> load balancer ->
>> server 22 london -> looks up saved requestbody !!!
>>
>> This is the problem point.  Your framework would be
>> depending on the request body save retrieve functionality
>> to be operational on all servers that might serve the
>> bounceback url request.  Regardless of whether they're
>> even in the same physical proximity or data realm.  They
>> must somehow share a backstored saved state, or depend on
>> the server that saved the state being available when it
>> needs it.
>>     
>
> Yes.  Normally any server application that depends on
> persistent session data would have to depend on consistently
> sharing that session data. 
Yes.  But timtowdti on how that information is distributed.  In my 
opinion any *framework* must not depend on the *application* having 
established a persistent backstore of shared session data, so that it 
can persist put/posts.  You're *significantly* constraining the 
parameters of the implementations utilizing the framework by requiring 
this, which I consider to be exactly what frameworks shouldn't do.  We 
may disagree.  :)
> The man page for "Session" says "tie" is too slow for web
> apps? 
*blank look*  Depends on the overhead of your tie I guess.  What are you 
tying?
>  Do I help anything by tying first and giving you a
> clone of the hash, then only saving the clone back to the
> tied hash after the response phase is done?
>   
Help as opposed to what?  Earlier availability of data, I might 
speculate.  But not sure what you're talking about exactly.
> I'm doing this for apps that would require users to register
> and associate an openid_url with an account username on the
> local app.  That requires some sort of server storage
> anyway.  If any OpenID server will do, and unique users
> aren't required to register, other modules are available.
>   
It requires server storage to know what usernames are available in this 
situation *yes*.  But that is merely at authentication time - not during 
the lifetime of the session.  An auth service is not a session service.

It does not require server session storage inherently to associate a 
session cookie with a user - the cookie has plenty of storage to do that 
itself.
>> Here's a thought.  what if you fully handled the post as
>> it came in - a short-time reprieve from having to do the
>> redirect - if you already know they WERE authenticated,
>> just accept their slightly expired ID, handle the form
>> submit appropriately, and then redirect when you're done. 
>> Have the bounceback go to the proper result page.  It
>> amounts to tri-state session, 'good', 're-auth', and
>> 'defunct'.
>>     
>
> Sort of defeats the purpose of session timeout, or how I
> think most people would think about that... but you could
> get this behavior by setting an infinite timeout.
>   
Your session times out when you say it times out.  And changes states 
when you say it changes states.  You can have two time periods - one 
being re-auth request time period, another being true expiration time 
period.  The purpose of a session timeout is to stop large time delta 
recycling of session data.  The purpose of re-auth time period is to 
nudge your flow into getting a new authentication token without the 
interruption of actual logout.  Neither of these is an infinite state, 
and would not be replicated by infinite timeout.
>> I was seriously thinking you were in a situation where you
>> honestly could not tell - maybe you set the cookie with an
>> expiration date, and its gone, its not being sent, you
>> have no idea who this request is coming from.  Its
>> different if you know.  If you do know they are(were)
>> authenticated, not receiving the request is just being
>> stubborn and inflexible, isn't it?
>>     
>
> Well yes, but that's the point of saving it while they
> re-authenticate ... session timeouts are usually used to
> make sure people can't come up to an idle computer and fill
> out some form with bogus stuff.
>   
How big a problem is that, exactly?  In my estimation, inconsequential.  
And is the result of the submit un-revokable?  The _application_ can do 
something trivial like display a confirmation page when the session 
state on submit was in the re-auth state.  Not an issue to me 
framework-wise because that is application layer logic - the framework 
should inform the application of the state, but the framework must not 
force the application to have a backstore session state so that it 
doesn't randomly drop form submits.  (particularly one that the 
framework scribbles on!)

And besides, if their auth-was-cached as I recall in the original 
supposition, the idle computer would still behave - and reauth - just 
like a properly attended one, making this entire point moot.

If it wasn't, the application still doesn't have to actually fully 
accept the post, just accept it to the point of asking for authenticated 
confirmation.  That way the application isn't interrupted and 
out-thought by the framework.
>>> Hrmm, if I passed the token as a separate cookie would
>>> that be an extra layer of security to "prove" they owned
>>> the session id?  Not sure about this stuff.
>>>       
>> Prove they own the session ID?
>>
>> It took me awhile to figure out what you are suggesting. 
>>
>> I assume this arises because you have a session key that rather than having the
>> inherent session data in it, is a sequence number that could be mangled by an end
>> user to try and step into an alternative session they don't own.
>>
>> Easy to fix that.  Brief recipe.  Make cookie value with a
>> simple signature.  ... So as long as you make it
>> reasonable difficult to mangle their cookies, They have
>> your token.  You've got to accept that they are who you
>> you authenticated that token for. 
>>     
>
> Awesome, thanks for explaining that, thanks for the tips.
> I will try to implement that checksum recipe in
> Apache2::Controller::Session regardless of whether they're
> using OpenID.
>   
Woot!  This is a good thing.  You might also consider using Data::UUID 
to create guids, instead of an arbitrary number.  They're easier to keep 
unique and harder to user mangle.

(er, as disclosure, that basic sign-a-token-with-md5 idea was learned 
from the perl cookbook) 

I have programmed entire (admitedly rather static) website that utilizes 
this pattern for its session/user state - you can hit any server in the 
farm and the session state is in the request, and verifiable as intact 
by the checksum.  No backstore hits/ties are necessary beyond logging in.

But when it comes to session states, you can set a whole stack of 
cookies to track various states, or mangle up your url paths and rewrite 
them in handlers, or whatever suits your situation to keep state across 
requests.  Backstore comes with weight and complication, I seriously 
believe that a framework should not depend on it.

David


Mime
View raw message