Re: htaccess using AuthCookieDBI not protecting thedirectory index

> From: André Warnier
> Date: Tue, 15 Sep 2009 01:50:05 +0200
> To: users@httpd.apache.org
>
>
> Tosh Cooey wrote:
> ...
>> Maybe I'll bug the author of the module now.
>>
> I just had a quick look at AuthCookieDBI, which subclasses AuthCookie.
> In AuthCookie->authenticate(), there is indeed a check for sub-requests,
> returning always OK in that case.
> In other words, I don't think that Apache subrequests, per se, are the
> cause of the problem.
> But maybe it is the fact that you are using this in a .htaccess file.
> Try setting
> PerlSetVar AuthCookieDebug 3
> in your .htaccess file.
> Then try again, and look at the server error log.
>

Hi André, thanks for your help! I set the debugging flag and here's
what came out:

[Mon Sep 21 13:45:22 2009] [error] auth_type Apache2::AuthCookieDBI
[Mon Sep 21 13:45:22 2009] [error]
r=Apache2::RequestRec=SCALAR(0x80212ed0) authtype=Apache2::AuthCookieDBI
[Mon Sep 21 13:45:22 2009] [error] auth_name berlin
[Mon Sep 21 13:45:22 2009] [error] ses_key_cookie
[Mon Sep 21 13:45:22 2009] [error] uri /berlin/


[Mon Sep 21 13:46:05 2009] [error] auth_type Apache2::AuthCookieDBI
[Mon Sep 21 13:46:05 2009] [error]
r=Apache2::RequestRec=SCALAR(0x805eead8) authtype=Apache2::AuthCookieDBI
[Mon Sep 21 13:46:05 2009] [error] auth_name berlin
[Mon Sep 21 13:46:05 2009] [error] ses_key_cookie
[Mon Sep 21 13:46:05 2009] [error] uri /berlin/LOGIN
[Mon Sep 21 13:46:05 2009] [error] Converting POST -> GET


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.

Anyway, I just wanted to follow up with you and to let you know that you
don't need to bang your head trying to solve this as I have solved it
with a redirect of / to /index.pl and then protecting all .pl files
within a enclosure.

Thanks for your help again...!

Tosh

--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: htaccess using AuthCookieDBI not protecting thedirectory index

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