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
