You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Fury <kl...@shetlandsoftware.com> on 2002/04/01 19:47:57 UTC
Proxy authentication against a mod_perl backend - how?
Subject line says it all.
I've recently reconfigured a web server to use the front-end proxy/back-end
mod_perl configuration. One application runs happily on the mod_perl
server, with static content being served from the proxy, and dynamic
requests forwarded to the backend.
However, I have a request to insert a bunch of static content onto the proxy
server, which is fine. As an added requirement, the content is to be
protected. Now, I could just use the standard Apache access files, but
they're ugly, and get slow as they grow.
Ideally, I'd like to use the backend database to hold the user information
used for authentication. How can I configure the proxy (which doesn't have
mod_perl) to authenticate against the back end?
My first thoughts were to use mod_proxy to forward requests for
/protected/login to the backend, where the authentication will be done.
Then, just redirect the request to another URL behind /protected. The
authentication information should be passed as part of the request, should
it not? I'd also reverse proxy the URL's - I don't think this would work if
I didn't.
Am I on the right track here or not?
-klm.
-------------------------------
Kenneth L. Miller, Consultant
Shetland Software Services Inc.
klm@shetlandsoftware.com
Re: Proxy authentication against a mod_perl backend - how?
Posted by Perrin Harkins <pe...@elem.com>.
> My first thoughts were to use mod_proxy to forward requests for
> /protected/login to the backend, where the authentication will be
done.
> Then, just redirect the request to another URL behind /protected. The
> authentication information should be passed as part of the request,
should
> it not?
Sure, but your proxy server won't be checking to see what it is. People
could go to any of your proctected pages freely if they know the URL.
Sounds like you're going to a lot of trouble to avoid using standard
auth to me. There are a number of auth modules out there which don't
need mod_perl, and you may find one that will play nicely with your
backend programs. Modules that auth against MySQL or LDAP servers
exist.
If you're determined to do auth on the backend, I would just let the
backend do the auth and serving of the static pages. It will dump them
out fast and let the proxy servers do the slow work of dribbling the
bytes out to clients.
- Perrin
Re: DBI: selectall_hasref incompatibility
Posted by "Rafiq Ismail (ADMIN)" <ra...@joshua.dreamthought.com>.
Fixed it with common sense - using "values %$result" to get back my
original struct. Time to upgrade DBI.
Cheers anyway. And a great big nasty insult to the wonderful guy who went
and made the selectall_hashref method do what it logically sounds like it
should do. ;)
fiq
On Tue, 2 Apr 2002, Rafiq Ismail (ADMIN) wrote:
> Got a slight problem here..
>
> Does anyone know why there was at some point a major change in the return
> value for DBI::selectall_hashref? And is there a depricated method which
> still uses the original prototype?
>
> My problem:
> -----------
>
> Using DBI V1.19 on my box, the reported prototype is:
> ""selectall_hashref""
> $ary_ref = $dbh->selectall_hashref($statement);
> $ary_ref = $dbh->selectall_hashref($statement, \%attr);
> $ary_ref = $dbh->selectall_hashref($statement, \%attr,
> @bind_values
>
>
> So i wrote shiney happy code and tried it on our production box.
>
>
> On the Production box, using DBI V1.21, the given prototype is:
>
> selectall_hashref
>
> $hash_ref = $dbh->selectall_hashref($statement, $key_field);
> $hash_ref = $dbh->selectall_hashref($statement, $key_field,
> \%attr);
> $hash_ref = $dbh->selectall_hashref($statement, $key_field,
> \%attr, @bind_values);
>
>
> hmm.. I sware that I saw something similar about a year ago.
>
> I don't want to go about rewriting code, so has anyone found some secret
> undocumented method which still use the original prototype.
>
>
> TIA,
>
> fiq
>
>
> "__ __ _ __ __
> | \/ | ___ __| | ___ _ __ _ __ | \/ | __ _ _ __
> | |\/| |/ _ \ / _` |/ _ \ '__| '_ \| |\/| |/ _` | '_ \
> | | | | (_) | (_| | __/ | | | | | | | | (_| | | | |
> |_| |_|\___/ \__,_|\___|_| |_| |_|_| |_|\__,_|_| |_|
> a pathetic example of his organic heritage"
> - Bad Religion
>
>
>
DBI: selectall_hasref incompatibility
Posted by "Rafiq Ismail (ADMIN)" <ra...@joshua.dreamthought.com>.
Got a slight problem here..
Does anyone know why there was at some point a major change in the return
value for DBI::selectall_hashref? And is there a depricated method which
still uses the original prototype?
My problem:
-----------
Using DBI V1.19 on my box, the reported prototype is:
""selectall_hashref""
$ary_ref = $dbh->selectall_hashref($statement);
$ary_ref = $dbh->selectall_hashref($statement, \%attr);
$ary_ref = $dbh->selectall_hashref($statement, \%attr,
@bind_values
So i wrote shiney happy code and tried it on our production box.
On the Production box, using DBI V1.21, the given prototype is:
selectall_hashref
$hash_ref = $dbh->selectall_hashref($statement, $key_field);
$hash_ref = $dbh->selectall_hashref($statement, $key_field,
\%attr);
$hash_ref = $dbh->selectall_hashref($statement, $key_field,
\%attr, @bind_values);
hmm.. I sware that I saw something similar about a year ago.
I don't want to go about rewriting code, so has anyone found some secret
undocumented method which still use the original prototype.
TIA,
fiq
"__ __ _ __ __
| \/ | ___ __| | ___ _ __ _ __ | \/ | __ _ _ __
| |\/| |/ _ \ / _` |/ _ \ '__| '_ \| |\/| |/ _` | '_ \
| | | | (_) | (_| | __/ | | | | | | | | (_| | | | |
|_| |_|\___/ \__,_|\___|_| |_| |_|_| |_|\__,_|_| |_|
a pathetic example of his organic heritage"
- Bad Religion
Re: Proxy authentication against a mod_perl backend - how?
Posted by Igor Sysoev <is...@rambler-co.ru>.
On Mon, 1 Apr 2002, Fury wrote:
> I've recently reconfigured a web server to use the front-end proxy/back-end
> mod_perl configuration. One application runs happily on the mod_perl
> server, with static content being served from the proxy, and dynamic
> requests forwarded to the backend.
>
> However, I have a request to insert a bunch of static content onto the proxy
> server, which is fine. As an added requirement, the content is to be
> protected. Now, I could just use the standard Apache access files, but
> they're ugly, and get slow as they grow.
>
> Ideally, I'd like to use the backend database to hold the user information
> used for authentication. How can I configure the proxy (which doesn't have
> mod_perl) to authenticate against the back end?
>
> My first thoughts were to use mod_proxy to forward requests for
> /protected/login to the backend, where the authentication will be done.
> Then, just redirect the request to another URL behind /protected. The
> authentication information should be passed as part of the request, should
> it not? I'd also reverse proxy the URL's - I don't think this would work if
> I didn't.
mod_accel can do such authorization with directive AccelRevalidateUser.
Authorization can be done via HTTP Basic authorization or cookie.
If directive is active the following happens:
1. if there is no cached response then it request is passed to backend;
2 if backend reponses with 200 code then reponse is cached;
3. if there is cached reponse then request is passed to backend with
If-Modified-Since header that set to Last-Modified header of cached
reponse;
4. if backend reponses with code 304 or 200 then cached or received
reponse send to client;
5. if backend reponses with any other codes then reponse send to client
but cached reponse is not deleted.
But this feature is usefull only if backend authorization and
304 (Not Modified) generating is cheaper then full reponse (200) generating.
Igor Sysoev
igor @ sysoev.ru