Re: [RFC] Apache::ProxyRewrite
On Tue, 14 Nov 2000 [EMAIL PROTECTED] wrote:
Please see http://www.apache.org/~ask/junk.txt
- ask
I will soon need something similar to this myself.
In my case, it will be necessary to authenticate on a user by user basis.
It would be good to extend this module to cope with this eventuality, with
pluggable backends to retrieve the passwords (I use LDAP but an
abstraction layer would be most flexible).
It may also be necessary to handle cookie based authentication/session
handling from the backend.
OK - so I know there are lots of issues to overcome. That's one reason why
I haven't attempted it yet ;-)
But functionality like this will allow me to proxy my users onto external
services without them worrying about multiple passwords, as remembering
just one seems to be beyond some of them !, and without me having to send
the "master" password out to third parties in plain text.
Hopefully I will be able to contribute some code back if the problems have
not already been solved by the time I need to implement a solution.
HTH,
Simon.
From "Christian Gilmore" [EMAIL PROTECTED]
Date 14 November 2000
To
"Modperl Mailing List (E-mail)" Time 16:54
[EMAIL PROTECTED]
Copy to (bcc: Simon Wilcox/BASE/WilliamsLea)
Bcc Simon Wilcox/BASE/WilliamsLea
Fax to
Subject [RFC] Apache::ProxyRewrite
I've completed work on a proxying module we needed here at work. I intend
to release it to the community, but first I want to get comments on its
current name and design. Perhaps there is a direction for it to grow
before initial release?
The Problem I Needed to Solve:
We need to proxy our external web services, but secure and insecure, to
our internal personnel while also doing authentication on the personnel's
behalf behind the scenes. In order to minimize muddying of customer data,
only a single "group" userid exists. This userid is to be used for the
purpose of authenticating and authorizing internal personnel to certain
areas of our external site.
The Solution:
Apache::ProxyRewrite will proxy content, rewriting arbitrary URLs embedded
in the content (if HTML) per run-time configuration. A configuration
example for the host www-internal.tivoli.com:
Location /
SetHandler perl-script
PerlHandlerProxyRewrite
RProxyTo http://www.tivoli.com
RProxyAuthInfo "BASIC dG32cvVwcnQ6amF4MzhfYXS="
RProxyAuthRedirect On
RProxyRewrite https://www.tivoli.com/secure /secure
/Location
Location /secure
SetHandler perl-script
PerlHandlerProxyRewrite
RProxyTo https://www.tivoli.com/secure
RProxyAuthInfo "BASIC dG32cvVwcnQ6amF4MzhfYXS="
RProxyAuthRedirect On
RProxyRewrite http://www.tivoli.com//
RProxyRewrite http://foo.bar.com/ /secure/foo
/Location
Requests for "/" will first be proxied to http://www.tivoli.com. The
content at the URL will be parsed (quickly via a single pass through the
code, not with HTML::Parser and its variants). There will be an implicit
rule that references to relative path of the argument to RProxyTo ("/" in
this case) in the document will be rewritten to the relative URI in the
current Location (also "/" in this case). Further, references to
https://www.tivoli.com/secure on the backend will be rewritten to /secure.
The RProxyAuthInfo directive allows for automatic authentication and
authorization for a predetermined userid. The RProxyAuthRedirect directive
allows the server to receive backend 401 responses and redirect the client
directly to that backend URI. I don't anticipate this directive having
much value to the general community, but it was a requirement of our
installation.
Please send comments, questions, flames (hopefully none of these!) back to
the list. I attempted to contact the owner of the Apache::RewritingProxy
package to no avail. His package, though, seems designed to rewrite
content, not URIs, so I think there's room for both.
Thanks,
Christian
-
Christian Gilmore
Infrastructure Tools Team Lead
Web Multimedia Development
Tivoli Systems, Inc.
__
This email contains proprietary information some or all of which may be
legally privileged. It is for the intended
Re: [RFC] Apache::ProxyRewrite
On Thu, 16 Nov 2000, Ask Bjoern Hansen wrote: On Tue, 14 Nov 2000 [EMAIL PROTECTED] wrote: Please see http://www.apache.org/~ask/junk.txt ah, shoot. My low cluerate beats everything. I obviously only meant to send that to Simon. Sorry. - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RFC] Apache::ProxyRewrite
I will soon need something similar to this myself.
In my case, it will be necessary to authenticate on a user by user basis.
It would be good to extend this module to cope with this eventuality, with
pluggable backends to retrieve the passwords (I use LDAP but an
abstraction layer would be most flexible).
It may also be necessary to handle cookie based authentication/session
handling from the backend.
OK - so I know there are lots of issues to overcome. That's one reason why
I haven't attempted it yet ;-)
But functionality like this will allow me to proxy my users onto external
services without them worrying about multiple passwords, as remembering
just one seems to be beyond some of them !, and without me having to send
the "master" password out to third parties in plain text.
Hopefully I will be able to contribute some code back if the problems have
not already been solved by the time I need to implement a solution.
HTH,
Simon.
From "Christian Gilmore" [EMAIL PROTECTED]
Date 14 November 2000
To
"Modperl Mailing List (E-mail)" Time 16:54
[EMAIL PROTECTED]
Copy to (bcc: Simon Wilcox/BASE/WilliamsLea)
Bcc Simon Wilcox/BASE/WilliamsLea
Fax to
Subject [RFC] Apache::ProxyRewrite
I've completed work on a proxying module we needed here at work. I intend
to release it to the community, but first I want to get comments on its
current name and design. Perhaps there is a direction for it to grow
before initial release?
The Problem I Needed to Solve:
We need to proxy our external web services, but secure and insecure, to
our internal personnel while also doing authentication on the personnel's
behalf behind the scenes. In order to minimize muddying of customer data,
only a single "group" userid exists. This userid is to be used for the
purpose of authenticating and authorizing internal personnel to certain
areas of our external site.
The Solution:
Apache::ProxyRewrite will proxy content, rewriting arbitrary URLs embedded
in the content (if HTML) per run-time configuration. A configuration
example for the host www-internal.tivoli.com:
Location /
SetHandler perl-script
PerlHandlerProxyRewrite
RProxyTo http://www.tivoli.com
RProxyAuthInfo "BASIC dG32cvVwcnQ6amF4MzhfYXS="
RProxyAuthRedirect On
RProxyRewrite https://www.tivoli.com/secure /secure
/Location
Location /secure
SetHandler perl-script
PerlHandlerProxyRewrite
RProxyTo https://www.tivoli.com/secure
RProxyAuthInfo "BASIC dG32cvVwcnQ6amF4MzhfYXS="
RProxyAuthRedirect On
RProxyRewrite http://www.tivoli.com//
RProxyRewrite http://foo.bar.com/ /secure/foo
/Location
Requests for "/" will first be proxied to http://www.tivoli.com. The
content at the URL will be parsed (quickly via a single pass through the
code, not with HTML::Parser and its variants). There will be an implicit
rule that references to relative path of the argument to RProxyTo ("/" in
this case) in the document will be rewritten to the relative URI in the
current Location (also "/" in this case). Further, references to
https://www.tivoli.com/secure on the backend will be rewritten to /secure.
The RProxyAuthInfo directive allows for automatic authentication and
authorization for a predetermined userid. The RProxyAuthRedirect directive
allows the server to receive backend 401 responses and redirect the client
directly to that backend URI. I don't anticipate this directive having
much value to the general community, but it was a requirement of our
installation.
Please send comments, questions, flames (hopefully none of these!) back to
the list. I attempted to contact the owner of the Apache::RewritingProxy
package to no avail. His package, though, seems designed to rewrite
content, not URIs, so I think there's room for both.
Thanks,
Christian
-
Christian Gilmore
Infrastructure Tools Team Lead
Web Multimedia Development
Tivoli Systems, Inc.
__
This email contains proprietary information some or all of which may be
legally privileged. It is for the intended recipient only. If an addressing
or transmission error has misdirected this email, please notify the author by
replying to this email. If you are not the intended recipient you must not
use, disclose, distribute, copy, print, or reply on
