Mark Hedges wrote:
On Mon, 29 Dec 2008, David Ihnen wrote:
Say the application's session times out, but the user
posts something by clicking submit.
They are redirected to the OpenID server but it says
they are still logged in and returns a positive
response.
But you can't know that they are authenticated without
redirecting them, because you dropped the session data
that held that information.
I think the obvious answer here is to keep the session
data around as long as the authentication is valid for.
Or keep this piece of state in a cookie so that it doesn't
vanish when your server decides to drop session state.
But if they time out, and click submit, but the independent
OpenID server says they're still logged in, or they re-auth
automatically with the server (e.g. VeriSign Seatbelt
Firefox plugin), then it should act as if they never timed
out, i.e. when they come back from the redirect cycle, it
should continue to submit whatever they clicked.
Maybe you could use something a bit more client side like an iframe
target, which CAN be resubmitted because the form still exists in state
on the page despite whats going on in the iframe.
- submit form target iframe
- iframe redirects for auth
- iframe gets auth
- success page activates parent re-submit
- submit form target iframe
- iframe success activates main page success state
Though that is, of course, specific to the application being programmed,
utilizing client-side javascript active stuff rather than particular web
server programming to transparently handle it on the server side using
basic html2.0 type structure.
I have to agree with others that a whole proxying layer to allow it
seems... excessive.
timtowtdi I guess.
David
