httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [users@httpd] htaccess using AuthCookieDBI not protecting the directory index
Date Mon, 21 Sep 2009 23:07:19 GMT
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 

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 

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:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message