Tosh Cooey wrote:
Everything looks fine, except this "Converting POST -> GET" part. I
don't know if it is, but I know that when the AUTH is working properly
that doesn't occur.
Ha. The POST -> GET conversion is a clever little trick of the author,
used only in some cases.
Reminder : A POST request - as opposed to a GET request - contains the
request parameters in the *body* of the request, not in the URL query
string.
The original request of the browser is not yet authenticated (iow it has
no cookie yet). It thus gets intercepted by the AuthCookieXX module.
The module sends back a login page. The user fills in the credentials,
and submits back the login page contents.
This new /login request comes in, and is handled by the login() sub.
The login sub verifies the credentials, and they match.
Now the login sub should forward the call to the original destination
which the user wanted in the first place (after already adding an auth
set-cookie header to the reponse).
But where does it now get this original request ?
Now backup one step :
If the original request was a GET, it is easy : when sending the login
page to the browser, include the original request URL as a hidden
parameter in the login form. When the user submits the login form, the
login() sub retrieves the original request's URL (including its query
string) from this hidden parameter, and can forward the request
internally in Apache via an internal redirect.
(If you look at the login form you receive initially, you will see this
hidden parameter).
However, if the original request was a POST, it is not so easy, because
the request contained the parameters in the body, not in the URL. Where
do we save that body while the login page goes back and forth ? you
cannot save it on the server side, because there is no such thing here
as a session context or similar. But you cannot send it back to the
browser either, and tell the browser, like, "keep it until you have
authenticated, then send it back".
Hack : convert the original POST request to a GET. In other words, read
the original body, decode it into parameters, assemble it back into a
query string, append it to the original URL, and save this all in the
hidden login form field mentioned earlier. Then when the login form is
submitted back by the browser, retrieve the original request (including
the query string with the "hidden body") again from the hidden form
field, and forward the request after authentication.
The request is now a GET instead of a POST, but the parameters are the
same. They are just encoded in the URL, instead of being in the request
body.
Rather smart, he ?
This clever trick would not work if the original unauthenticated POST
contained for example a big file, among other reasons because of the
limitations in size (and encoding) of a URL. But in 95% of practical
cases, it works just fine. Just design your site so that you don't have
the first request being a large POST..
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org