Re: Catalyst Redirect Hints?

Store the posted variables on behalf of the browser. Create a unique key which you can later use to reference that posted content (and its origin), and serve the login page including that key as a hidden variable in the login form. If the login succeeds, serve the original form with the saved variables filled in. No redirects involved. Of course you need some code to clean up that non-authenticated posted content, if the login fails (or time runs out).

I don't know the Catalyst specifics to do that, but that's how I'd do it - i.e. create a non-authenticated session which results in serving the login form.

Comment on Re: Catalyst Redirect Hints?

Replies are listed 'Best First'.
Re^2: Catalyst Redirect Hints? by saberworks (Curate) on Mar 25, 2009 at 22:00 UTC
The problem with this is that you can't present the original form with the values filled in if the form contains file upload widgets or password fields. Browsers often refuse to fill those out because you can be tricked into uploading files you didn't intend to, /etc/passwd or something. But storing all the posted content and then forwarding to the processing page for the original form may work somewhat. Usually when you hit a protected page and you're not logged in, you get forwarded to the login page (via an internal or external redirect). You will have to ensure it's an internal redirect so you still have access to the POST content or don't redirect at all, intercept the request and present the login form at the original URL they requested.	[reply]
Re^3: Catalyst Redirect Hints? by shmem (Chancellor) on Mar 25, 2009 at 22:52 UTC
Well it depends on the design of the app and the data being POSTed, of course. I'd not serve a file upload form nor process it without proper authentication, unless I'd purpose being flooded with SPAM of all sorts. But the requirement "allow POSTing first, authenticate later" looks a bit weird to me, I have to confess.	[reply]