Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 9:37 AM -0400, Michael [EMAIL PROTECTED] wrote: The reason this question is mod_perl related is that he is doing the initial authentication using mod_perl, and is creating a cookie based ticket. But he wants that ticket to also be accepted by a non-mod_perl enabled server (ie a front end proxy). So the database connection has to persist from the mod_perl authentication scheme to the backend software? Interesting... Does that work? This isn't really an issue with database connections. It's just the authentication data/method that needs to persist for both. And that is handled by a cookie/ticket authentication. Thanks to Cees Hek [EMAIL PROTECTED] for helping me find a module I had lost track of. The module is mod_auth_tkt and can be found here: http://www.openfusion.com.au/labs/mod_auth_tkt/ I'm on my way to having an elegant solution now. Thanks to all who responded. Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 9:45 AM -0400, Michael [EMAIL PROTECTED] wrote: Any other suggestions? I'd think you'd want to have the same authentication process for both, and a shared database (or something) to store the session data. Have the front-end do the login part, pass the client to the backend, which discovers that the client is already authenticated. Using tickets for authentication will work with both the front and backend servers. I was having problems finding a solution which had an apache module (written in C) plus support/examples for perl to use in the backend. With thanks to Cees Hek [EMAIL PROTECTED] I found mod_auth_tkt which does just what I need. Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good morning, On 26/8/03 at 8:26 PM +0200, Thomas Klausner [EMAIL PROTECTED] wrote: Hi! On Die, Aug 26, 2003 at 09:06:05 +1000, Charlie Garrison wrote: I need to protect resources in both the static (proxy) front-end and the mod_perl back-end. I have been using standard http authentication which works pretty well except for not allowing a proper logout function and some caching issues which result in occasional false FORBIDDEN responses. Since a proper logout has become an important requirement, I am looking for other solutions. Did you take a look at Apache::AuthCookie? http://search.cpan.org/author/MSCHOUT/Apache-AuthCookie-3.04/ Yes, I've looked at Auth::Cookie, and if I needed a mod_perl only solution, it would be perfect. Since I need the user credentials in the mod_perl app, I'm not happy to leave all authentication to the front-end proxy server unless it sets the user credentials (or some other values) before passing along the request. As AuthCookie is a mod_perl handler, you would have to put the Authentification into the backend. Depending on how you generate the session key (i.e. the value of the Auth Cookie), you should be able to use the cookie in the frontend using one of the modules you mentioned (although I don't know any of them..) Which sort of brings me back full circle. I'm happy to write the backend (modperl) support myself for whatever the frontend module requires. But the module that I would choose (mod_auth_mda) doesn't have perl examples for creating the MD5 cookie, and I'm only borderline confident that I can take their java examples along with the documentation to figure out perl routines for the cookie creation. I'm still hoping someone has already solved this issue of shared authentication scheme between static frontend and modperl backend servers. Thanks, Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 2:49 PM +1000, Cees Hek [EMAIL PROTECTED] wrote: Umm, use Apache::DBI, that's what it's for. It was easy to miss in the email if you skimmed it, but he is looking for a C based module, so any perl based solutions are out. The reason this question is mod_perl related is that he is doing the initial authentication using mod_perl, and is creating a cookie based ticket. But he wants that ticket to also be accepted by a non-mod_perl enabled server (ie a front end proxy). Thanks for the clarification. And the requirement for something that works in both modperl and non-modperl servers is also part of the subject line. But I'll try to make the problem/requirements more clear in future emails. Thanks, Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 12:05 AM -0400, Michael [EMAIL PROTECTED] wrote: The second one, Cookie Authentication with MySQL, looks like a very good option, except for two issues. Fist, it doesn't support the 'require group...' directive. And second, it doesn't appear to cache mysql connections so I am concerned about the increased load from lots of quick connections. Umm, use Apache::DBI, that's what it's for. Except that I'm looking for a solution which will also work in the static (proxy) front-end. I'm currently using Apache::DBI for the backend and it works well. I also want a solution which doesn't rely on browser based http authentication since logging out is a requirement. I feel that someone must have already solved this issue so any suggestions or advice would be appreciated. Are there any modules which I have missed? Are the perceived problems with the above modules really an issue, or should I be able to use one of them without any problems. I haven't been 100% happy with any of the systems written by other people so I've always just written my own. It's a rather simple process. Right now I have one method that uses cookies in one module, another that uses cookies but splits things up into separate modules, and a third that adds a (md5 hash) parameter to the URI. All work very well, though I prefer the cookie method myself. Do you also write the apache module for the frontend server? I'm very competent at perl, but not competent enough to write an apache module. Any other suggestions? Thanks, Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Ticket/cookie based authentication for mod_perl and static frontend
Good evening, I have done a bit of research and found some possible solutions, but none of them seem to be exactly what I want. First, the problem I need to solve... I need to protect resources in both the static (proxy) front-end and the mod_perl back-end. I have been using standard http authentication which works pretty well except for not allowing a proper logout function and some caching issues which result in occasional false FORBIDDEN responses. Since a proper logout has become an important requirement, I am looking for other solutions. Since I need the user credentials in the mod_perl app, I'm not happy to leave all authentication to the front-end proxy server unless it sets the user credentials (or some other values) before passing along the request. I have looked at the following apache modules (for v1.3): Cookie Authentication Version 1.9 Fake Basic Authentication using Cookies Module homepage at ftp://ftp.kciLink.com/pub/mod_auth_cookie.c.gz Cookie Authentication with MySQLVersion 1.0 Authentication against a MySQL database with a cryptographically secure cookie. Module homepage at http://www.qwk.net/opensource/mod_auth_cookie_mysql/ mod_auth_mdaVersion 2.1 Realms for document tree and fast login for user using MD5 signed cookies. Module homepage at http://www.frogdot.org/mod_auth_mda/ The first one, Cookie Authentication, looks nice and simple and should do what I want. It sets the user credentials from a cookie to be processed by another module in the request chain. But I'd prefer to have the authentication handled by the same module. There are some caching issues with the current auth module which I'd like to avoid (by not using the current module any longer). The second one, Cookie Authentication with MySQL, looks like a very good option, except for two issues. Fist, it doesn't support the 'require group...' directive. And second, it doesn't appear to cache mysql connections so I am concerned about the increased load from lots of quick connections. The third one, mod_auth_mda, is probably my favourite choice (for a variety of reasons). But it doesn't have any sample code for creating the MD5 signed cookies with perl, and I'm not sure I feel confident about creating the needed functions myself. All the sample code is written in Java. Additionally, all of the above solutions require the use of cookies. It would be nice if I could also use a URI (eg. path info) rather than just a cookie solution. I feel that someone must have already solved this issue so any suggestions or advice would be appreciated. Are there any modules which I have missed? Are the perceived problems with the above modules really an issue, or should I be able to use one of them without any problems. Thanks, Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Transparent front-end proxying for many VirtualHosts
Good afternoon, On 5/3/03 at 3:30 PM, Andrew Ho [EMAIL PROTECTED] wrote: I have an Apache with many VirtualHosts, and I want to setup proxying so that a lightweight frontend Apache with mod_rewrite/mod_proxy proxies Apache::Registry script requests back to a heavyweight backend Apache running on a localhost-only port. I want to simplify my configuration in two ways. I'd prefer not to maintain two sets of VirtualHost configuration data, and I'd like it if the block that proxies .pl files to the backend proxy not be replicated per VirtualHost. I use mod_macro and IfDefine directives to simplify virtual host setups with backend server. First I do the bulk of the config in httpd.conf as usual (seperate conf files for frontend and mod_perl) and then use Include directive to load files (one for each virt host) from a directory. Each included conf file is loaded by both frontend mod_perl servers and IfDefine controls which parts are used for each server. This is a short sample file (the Use directives are for mod_macro): IfDefine IS_FRONT_END VirtualHost 10.8.168.70:80 Use mSiteRoot gcs garrison.com.au Use mSiteLogs_frontend gcs Use mSiteUserGroup gcs Use mSiteRootDirOptions gcs Use mSiteCgiBinDirOptions gcs Use mSetupRewrite Use mSiteRewriteRules /VirtualHost /IfDefine IfDefine IS_PERL VirtualHost 10.8.168.70:8520 Use mSiteRoot gcs garrison.com.au Use mSiteLogs_modperl gcs Use mSiteUserGroup gcs Use mSiteRootDirOptions gcs Use mSitePerlBinDirOptions gcs /VirtualHost /IfDefine This setup doesn't put all the rewrite config in the main conf file, but it does centralize it all to make maintenance much easier. And there is only one conf file for each virt host. Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia
Re: WEb hosting..
Good afternoon, On 28/2/03 at 5:26 PM, Stas Bekman [EMAIL PROTECTED] wrote: http://perl.apache.org/help/isps.html As usual, if you know of ISPs that aren't listed there (or listed, but not providing modperl support any longer), please let us know. Make-Tracks (based in Australia) offers hosting for mod_perl sites. For more information see http://www.make-tracks.com/ or for specific hosting details see http://www.make-tracks.com/hosting.html. Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia
Re: question about using a proxy with mod_perl
Good afternoon,
On 17/10/02 at 2:46 PM, Lyle Brooks [EMAIL PROTECTED] wrote:
To do what you are trying to do, I believe you'll need to use some RewriteCond
directives, something like (read: I'm just doing this from memory, you'll
need to test)...
RewriteCond %{HTTP_HOST} ^b
RewriteRule ^/(.*) http://b.blah.com:4374/$1 [P,L]
I don't think the RewriteCond is needed. I just use something like the following
to proxy all files ending in .cgi:
RewriteRule ^/(.*).cgi(.*)$http://%{HTTP_HOST}:8001/$1.cgi$2 [P]
I also have lots of domain names that need to get passed to the back-end server.
My setup gets even more fun when taking into account the internal NAT addresses
that are needed for proxying but local dns serves public external addresses. I
had a fun weekend learning about views and acl's in bind to get around that
problem. (And then patching output from oDNS to support it.)
Charlie
--
Charlie Garrison[EMAIL PROTECTED]
PO Box 141, Windsor, NSW 2756, Australia
Re: caching dynamic content in the reverse proxy
Good afternoon, On 6/9/02 at 12:12 AM, pascal barbedor [EMAIL PROTECTED] wrote: but any content sent by a modperl handler is not cached although I set headers Last-Modified and Expires to compatibles dates (with Apache::Util::ht_time) and Cache-content to public from the modperl handler with $r-header_out.. Has any one succeeeded is caching dynamic content in this configuration When I have caching problems, I run my pages through cachability to find out where they are failing. Check it out at: http://www.web-caching.com/cgi-web-caching/cacheability.py It reports on page headers as well as gives useful info like the following: This object doesn't have any explicit freshness information set, so a cache may use Last-Modified to determine how fresh it is with an adaptive TTL (at this time, it could be, depending on the adaptive percent used, considered fresh for: 2 weeks 20 hr (20%), 5 weeks 2 days (50%), 10 weeks 4 days (100%)). It can be validated with Last-Modified. The site is a great resource for a variety of caching issues. Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia
Re: HELP??? Installation on MAC OS X
G'day,
I am trying to install mod perl on the Apple OS X Server platform.
I can compile the code OK, both as static and as a DSO but when I
try to restart the apache server, I get all sorts of errors.
I found that it was already compiled, but the needed lines in
httpd.conf were missing. Add the following two lines (at the end of
the appropriate lists):
LoadModule perl_module libexec/httpd/libperl.so
AddModule mod_perl.c
And then add some mod_per directives (I've used the perl/perl syntax):
perl
require /etc/httpd/startup.pl; # contains 'use' statements, etc.
$Location{'/perl-status'}-{SetHandler} = 'perl-script';
$Location{'/perl-status'}-{PerlHandler} = 'Apache::Status';
$Location{'/perl-status'}-{order} = 'deny,allow';
$Location{'/perl-status'}-{'deny from'} = 'all';
$Location{'/perl-status'}-{'allow from'} = '.your.domain.com';
$Files{'~ \.pl$'}-{SetHandler} = 'perl-script';
$Files{'~ \.pl$'}-{PerlHandler} = 'Apache::Registry';
$Files{'~ \.pl$'}-{Options} = 'ExecCGI';
/perl
I'm now able to do all development/testing on my box. I was able to
install all needed modules via CPAN without any trouble.
This was one of the reasons I wanted this OS, so I'm very happy.
Charlie
--
+--+
| Charlie Garrison [EMAIL PROTECTED] |
| Garrison Computer Serviceshttp://www.garrison.com.au |
| PO Box 141 |
| Windsor NSW 2756 Australia Ph: +61 2 4575-5247 |
+--+
