Reconstructing a POST request and redirecting?

[Robert Oschler]

I am working on a PHP 4 app that interacts with an external authorization
server. The external server does "third-party" authorization of users.
So I do the following:

1) Each of my PHP scripts has an include file (require_once) that checks to
see if the current user has recently been authorized.

2) If not, the user is "handed off" to the external server. I do this by
building the necessary URL for authorization and using refresh to perform
the redirection.

3) The external server authorizes the user by asking them to login.

4) The external server then redirects the user's browser back to a
predefined URL on my server.

I have created a MySQL database, indexed by user ID, that stores the current
URL request (to my server), the request type (GET/POST), and the GET & POST
arguments.

Before I hand the user off to the external server, I store all that
information in the database. This all works fine so far.

What I need to do now, in item 4 above, is look up the URL request info from
the database, reconstruct the GET/POST request, and redirect the user's
browser to that reconstructed destination.

All I need is some helpful code snippets to show me a clean way to
reconstruct POST requests; getting the headers right and such, and telling
the user's browser to execute/fetch that POST request. If it matters, I am
using the PEAR libraries for HTTP requests and I have no problem using
Javascript based solutions.

Does anybody have a code snippet that could save me some time here? Any
caveats or warnings?

Thanks.

[Andy Hassall]

On Sun, 24 Jul 2005 17:16:15 -0400, "Robert Oschler"
<no************@nospam.com> wrote:

I am working on a PHP 4 app that interacts with an external authorization
server. The external server does "third-party" authorization of users.
So I do the following:

1) Each of my PHP scripts has an include file (require_once) that checks to
see if the current user has recently been authorized.

2) If not, the user is "handed off" to the external server. I do this by
building the necessary URL for authorization and using refresh to perform
the redirection.

3) The external server authorizes the user by asking them to login.

4) The external server then redirects the user's browser back to a
predefined URL on my server.

I have created a MySQL database, indexed by user ID, that stores the current
URL request (to my server), the request type (GET/POST), and the GET & POST
arguments.

Before I hand the user off to the external server, I store all that
information in the database. This all works fine so far.

What I need to do now, in item 4 above, is look up the URL request info from
the database, reconstruct the GET/POST request, and redirect the user's
browser to that reconstructed destination.

All I need is some helpful code snippets to show me a clean way to
reconstruct POST requests; getting the headers right and such, and telling
the user's browser to execute/fetch that POST request. If it matters, I am
using the PEAR libraries for HTTP requests and I have no problem using
Javascript based solutions.

Does anybody have a code snippet that could save me some time here? Any
caveats or warnings?

I do a similar thing for GET requests on an intranet at work, except I pass
the "return URL" to the authentication page - I've chickened out of POST
requests as it's reasonably safe to assume that nobody will be POSTing in from
an unauthenticated area into the authenticated area (at the moment anyway), and
the POST data may be too long to encode in a GET request.

You don't have that problem as you say you're storing it in a database -
that's a decent idea. Could also presumably do that in a session variable
reasonably safely as well.

If it's a GET request, then you can just reconstruct the URL and
header("Location: $absolute_url") to it. Main thing to watch out for is array
parameters (i.e. value[]=x;value[]=y or value[1]=x;value[3]=y) etc.

What sort of format are you using to store the data in the DB? Do you
basically end up with a copy of the full (possibly multi-dimensional) $_GET
array as it was before you went into the authentication section?

If it's POST then you can't redirect into it, but you can reproduce all the
form data using input type="hidden", fields and present a submit button to post
back to the correct location.

--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

[Robert Oschler]

"Andy Hassall" <an**@andyh.co.uk> wrote in message
news:p5********************************@4ax.com...

On Sun, 24 Jul 2005 17:16:15 -0400, "Robert Oschler"
<no************@nospam.com> wrote:

I do a similar thing for GET requests on an intranet at work, except I pass the "return URL" to the authentication page - I've chickened out of POST
requests as it's reasonably safe to assume that nobody will be POSTing in from an unauthenticated area into the authenticated area (at the moment anyway), and the POST data may be too long to encode in a GET request.

You don't have that problem as you say you're storing it in a database -
that's a decent idea. Could also presumably do that in a session variable
reasonably safely as well.

If it's a GET request, then you can just reconstruct the URL and
header("Location: $absolute_url") to it. Main thing to watch out for is array parameters (i.e. value[]=x;value[]=y or value[1]=x;value[3]=y) etc.

What sort of format are you using to store the data in the DB? Do you
basically end up with a copy of the full (possibly multi-dimensional) $_GET array as it was before you went into the authentication section?

If it's POST then you can't redirect into it, but you can reproduce all the form data using input type="hidden", fields and present a submit button to post back to the correct location.

--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

Andy,

You basically answered my question when you told me that you can't redirect
a POST. I'll have to modify my POST target scripts to look for a URL
argument that tells them to pull the POST data from the database instead of
the $_POST array. Not too hard.

Thanks.