Tosh Cooey wrote:
Ha. The POST -> GET conversion is a clever little trick of the author, used only in some cases.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.
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-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|