[Agavi-Users] Question on POST data redirection after authentication

[vikram.m...@googlemail.com]

Hi all,

I have a Web form that asks the user for some input and then offers a
'save to database' option. The form data is then POSTed to a procedure
that writes the corresponding database record. However, this option
expects the user to be logged in. If the user is not logged in, then
on selecting this option, they are instead redirected to a login form.

My question is: if the user is not logged in, how do I correctly
transfer the POSTed form data from the initial form all the way
through the login process and then re-POST it back to the
writeRecord() procedure?

I considered a couple of options:
-- Transferring the data from request to request using GET. However
one of the data values is a reasonably large XML document which I
would then need to somehow serialize before passing along. Have not
explored this further but can do if this is the best available option.
-- Storing the POST data in a session if the user is not
authenticated, and then retrieving it post-authentication. However, in
this case, I'm not sure how to POST it back to the target action.
Also, I suspect it would not work in case the client doesn't permit
session cookies.

Any advice would be much appreciated. Many thanks.

Vikram Vaswani

_______________________________________________
users mailing list
us...@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/users

[Simon Holywell]

You could put the contents into a db table with a pending flag and then just pass the row id and a secret/hash (to stop people changing the id) via get.

You could have another table in which you save the row and then as above but copy the row from one table to the other once authenticated.

Another option would be to use a temp file which would be similar to storing it in a session anyway.

You could also stick the record into memcached or apc and access it as above.

Doesn't your login mechanism use sessions anyway?

I am not sure how you would do the reposting though.

[Michal]

On Fri, Jan 29, 2010 at 7:21 AM, Simon Holywell <si...@holywell.com.au> wrote:
> Doesn't your login mechanism use sessions anyway?

Even if cookies are required to use the app, I think there is a
different reason to not use session variables here (or at least not
use them naively): the case of multiple windows/tabs being open, all
on your site.

For example, if the user submits the form (each with different data)
from 2 tabs. The user is not logged in, so will be redirected to the
login on both. Then a mechanism must be in place to ensure the right
window accesses the right session variable (say to show the correct
data/message after saving).

(This is a pet peeve of mine: I find it *so* annoying when I cannot do
multiple things on one site. I suspect it can be confusing to people
that don't know what's going on as well)

So I would:

- Redirect to a login page that has a GET variable for the id/hash of
the row (as mentioned previously)

- Or, if you want "clean" urls on the page, you could *not* redirect
to another page, but show the login right on the target page of the
POST of the initial form. You could insert hidden inputs into the form
(say the id/hash of the row), that the login action could then process
(say, creates a forwardcontainer to an action that handles the saving
to database.)

Michal.

[vikram.m...@googlemail.com]

Hi Simon,

> From: "Simon Holywell" <si...@holywell.com.au>
> Subject: Re: [Agavi-Users] Question on POST data redirection after
>        authentication
> To: us...@lists.agavi.org
> Message-ID: <nG52vRmvcR...@smtp.googlemail.com>
> Content-Type: text/plain; charset=UTF-8
>
> You could put the contents into a db table with a pending flag and then just pass the row id and a secret/hash (to stop people changing the id) via get.
>
> You could have another table in which you save the row and then as above but copy the row from one table to the other once authenticated.
>
> Another option would be to use a temp file which would be similar to storing it in a session anyway.
>
> You could also stick the record into memcached or apc and access it as above.

Interesting ideas and ones I hadn't considered. I specifically like
the 'temporary table/pass row ID and secret' one. Let me try that out.

> Doesn't your login mechanism use sessions anyway?

It does. Good point, that didn't occur to me earlier :)

> I am not sure how you would do the reposting though.

Yup, that was where I was held up too. I was thinking of generating a
new HTTP request with the POST data, but handling the response is a
little tricky.

Any other suggestions for optimal ways to solve this from others on the list?

Vikram