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
> PerlHandler ProxyRewrite
>
> RProxyTo http://www.tivoli.com
> RProxyAuthInfo "BASIC dG32cvVwcnQ6amF4MzhfYXS="
> RProxyAuthRedirect On
> RProxyRewrite https://www.tivoli.com/secure /secure
> </Location>
>
> <Location /secure>
> SetHandler perl-script
> PerlHandler ProxyRewrite
>
> 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 this email.
>
>
>
--
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]
