SSO Design help

I’m still working on my SSO system (once I’m done, I’m hoping to
abstract the design and provide either a step-by-step guide or a
plugin), and I’ve got a few questions (although these could just be a
regular sign-on system… they just happen to be cropping up during
designing the SSO thing):

Say a site has a 30 minute timer on their sessions.
Bob is logged into site A, busy filling out an absolutely gigantic form
(not that I suggest this is a good thing to do, but if I plan on
abstracting this, I need to provide for non-best-practice
implementation). It takes him longer than the allotted 30 minutes to
finish this form, so by the time he clicks on the submit button, he’s
already been logged out.

The first step here is to have the login system capture the request
type, the request URI, and the params hash.

When he’s finished logging in, the application should post the data it
captured in the first step, and show him the results just like nothing
ever happened.

Getting in my way is the following fact: redirects are always GET, not
POST. Other than using a redirect, the only option I can come up with
is to basically write an empty page, then do an AJAX request and write
it over the top of the empty page.

Now, to get around this, I could create an action that would accept the
parameters as a GET, instead. This is do-able, although I’m pretty sure
it violates the principles of REST (which I haven’t fully adopted yet,
but I’d rather be as close to them as possible).

If I were to implement the second solution, it would give rise to the
question: is there a simple way, given the params hash, to convert that
back into the GET request style parameters?

IE… given: {:user => {:name => ‘bob’, :email => ‘[email protected]’}}
I would need
user[name]=bob&user[email][email protected]

I could very easily write my own function to do that, I’m just curious
to know whether it already exists… given the necessity of the exact
opposite of it existing, I thought it might.

I would suggest that you put a before filter that precedes the authorize
user filter that will capture the post in session which can later be
extracted.

Keynan P. wrote:

I would suggest that you put a before filter that precedes the authorize
user filter that will capture the post in session which can later be
extracted.

Assuming I’m reading you right, you’re saying I should perform the POST
opertaion before re-authenticating. If the session cookie is expired, I
can no longer access their user information, meaning that I couldn’t
perform any operation which required knowledge of who was doing it…
therefore invalidating your suggestion.