Re: [OTish] Version Control?
Hey Jim -- Also, Randal Schwartz wrote about cvs is a slightly more general setting: http://www.linux-mag.com/2002-07/perl_01.html The system we use goes a bit beyond even what Randal describes (although, he is on a similar track). In a nutshell, the Apache httpd.conf file is templatized to replace elements such as the IP address, host name and path names with variables. To start the server for a particular environment the developer runs a Perl program which creates a custom httpd.conf This is so close to what I recently put together one would have to worry about plagarism :-) I took it one step further, in that my setup script will configure not only the base http config files (for both proxy and app server), but also all the database configuration scripts, and application configurations. I did an install for a fellow developer today in about 5 minutes - complete proxy/app server config, build and populate database tables. I had to edit one file, which in turn was used to create the customized configuration files. I don't keep the base config files in CVS - yet. All source is in CVS, but I haven't got around to moving the config into CVS. Regarding deployment, I wrote a tool which goes into CVS and extracts tagged modules. The extracted code is placed into a tar archive with a few other files which indicate where the code is to be installed, plus a few other goodies. I can then give this deployment archive to our sysadmin who can simply type deploy --install the-file.dar and the code gets installed. We have separate deployment files for the perl libs, the Mason components, images, and a few other odds and ends. It works well, and it's very easy. Why a custom deploy tool? I didn't like the idea of using CVS on the production server, which is in a very tightly controlled environment. I doubt if I could have enticed the network folks to open the firewall to let CVS traffic through in any case Cheers! -klm.
Prototypes and $r
Got a phone call yesterday from a user who was complaining that every few
times a link was clicked on they were getting an Internal Server Error.
They could click back, try again, and be successful. Further investigation
led me to find that one of the instances of my back end server was always
generating an error.
Restarts would not fix the problem - one or two of the app servers would
always throw errors
The error was this:
[Mon Sep 23 19:12:21 2002] [error] Can't call method dir_config on an
undefined value at /webroot/lib/Husky/Web/Apache
/MasonHandler.pm line 68.
The line in question is this:
my $appl_id = $r-dir_config( 'ApplID' );
So, you can see that '$r' was undefined.
The interesting thing is that the handler that's invoked for this request
has a prototype:
sub handler( $$ ) { my $class = shift; my $r = shift; ... }
and the handler is either invoked by Apache directly, or from internal logic
when a request is passed off. The handler is invoked in one of two ways:
__PACKAGE__-a_method_name( $r );
or
Foo::Bar::Bah-a_method_name( $r );
Now, it appears that every now and then the class reference is NOT being
sent; hence, $class actually contains $r, and $r is undefined. This is
obviously bad, since $r-dir_config dies a horrible death.
Has anyone had a problem with this? Is there something that might give me a
clue as to why this is failing? In the meantime, I've when back to
referencing the sub directly, as opposed to going through the class. It
works, but it's not as nice as a class method...
Cheers!
-klm.
+-+-+
| Kenneth (Ken) L. Miller | There are 10 kinds of people in the |
| Shetland Software Services Inc. | world: Those who understand binary, |
| [EMAIL PROTECTED]| and those who don't. (unknown) |
+-+-+
When is Apache-server-log_error available?
I'd like to write some status messages to the error_log during server startup. So, I tried Apache-server-log_error( ... ) but it doesn't work. This works fine in the child processes. Is the log file not ready to write to during server startup? Printing to STDERR does not work either. It's not that important, but I'd like to know regardless. Cheers! -klm. +-+-+ | Kenneth L. Miller | There are 10 kinds of people in the | | Shetland Software Services Inc. | world: Those who understand binary, | | [EMAIL PROTECTED]| and those who don't. (unknown) | +-+-+
Apache::Reload -- can't locate main.pm?
I've been successfully using Apache::Reload for a few weeks now. However, I installed it on my home development system, and I'm getting this error when accessing a module that contains 'use Apache::Reload': [Mon Aug 26 09:59:12 2002] [error] Can't locate main.pm in INC (INC contains: ... at /home/miller/lib/perl5/site_perl/5.6.1/Apache/Reload.pm line 132. (yes, I install some modules under my own root tree - it keeps the base distribution nice and clean) What's main.pm, and why can't Apache::Reload find it? I've searched the archives, but have had little success in finding anything interesting. Apache1.3.26, mod_perl 1.26. Cheers! -klm.
Apache::AuthCookie weirdness
I'm experiencing a really strange problem with Apache::AuthCookie and Internet Explorer. Every now and then when I try and access a protected URL, I never see the login page. If I close the window, and open a new one, it works just fine. This is the case even if there are other windows open. In otherwords, I don't have to close all the IE windows to get in. I do not know if this same error occurs with Mozilla. If I inspect the logs, I see this: (with Apache::AuthCookie debugging turned on): (Application Server Error Log) [Thu Jul 11 09:06:51 2002] [error] auth_type Foo::Apache::AuthCookieHandler [Thu Jul 11 09:06:51 2002] [error] auth_name Bar [Thu Jul 11 09:06:51 2002] [error] ses_key_cookie [Thu Jul 11 09:06:51 2002] [error] uri /rc/ [Thu Jul 11 09:06:51 2002] [error] auth_type Foo::Apache::AuthCookieHandler [Thu Jul 11 09:06:51 2002] [error] auth_name Bar [Thu Jul 11 09:06:51 2002] [error] ses_key_cookie [Thu Jul 11 09:06:51 2002] [error] uri /rc/ [Thu Jul 11 09:06:51 2002] [error] auth_type Foo::Apache::AuthCookieHandler [Thu Jul 11 09:06:51 2002] [error] auth_name Bar [Thu Jul 11 09:06:51 2002] [error] ses_key_cookie [Thu Jul 11 09:06:51 2002] [error] uri /rc/ [Thu Jul 11 09:06:51 2002] [error] auth_type Foo::Apache::AuthCookieHandler [Thu Jul 11 09:06:51 2002] [error] auth_name Bar [Thu Jul 11 09:06:51 2002] [error] ses_key_cookie [Thu Jul 11 09:06:51 2002] [error] uri /rc/ (Application Server Access Log) 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.0 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.0 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.0 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.0 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.0 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.0 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.0 403 1542 127.0.0.1 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.0 403 1542 The browser and the server are locked in this conversation where the browser continually requests the protected URI. If I look in the access logs, I see this: (Front-end light Proxy Logs) xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /styles.css HTTP/1.1 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.1 200 1542 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /styles.css HTTP/1.1 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.1 200 1542 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /styles.css HTTP/1.1 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.1 200 1542 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /styles.css HTTP/1.1 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.1 200 1542 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /styles.css HTTP/1.1 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.1 200 1542 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /styles.css HTTP/1.1 200 3495 xxx.10.67.255 - - [11/Jul/2002:09:06:51 -0600] GET /rc/ HTTP/1.1 200 1542 Any ideas what's going on? It almost seems like AuthCookie is getting confused and not redirecting the user to the correct URL - instead of the login page, it get's redirected back to the initial url, which is protected, and thus starts the entire cycle over again. Proxy: Apache/1.3.23 (Unix) mod_gzip/1.3.19.1a mod_ssl/2.8.7 OpenSSL/0.9.6c App: Apache/1.3.23 (Unix) mod_perl/1.26 Perl: 5.6.1 Apache::AuthCookie: 3.02 -klm.
Re: mod_perl help
I had this same problem with installing some precompiled packages from sunfreeware, such as libdb. My only recommendation is to scrap the installed packages for anything related to perl, including perl itself. And note that even though it says that Perl was compiled with GCC, the options selected may be generally incompatibile with how perl works with dynamically loaded modules. This was the conclusion that I same to, anyways... Build the stuff yourself. You'll save yourself a lot of headaches. BTW, when compiling perl for Solaris 8, you'll need to do this: /Configure -Dcc='gcc -B/usr/ccs/bin/' If you don't have the GNU linker/assember installed, then you can skip the -Dcc option. Once I built everything myself, I had NO problems. -klm. - Original Message - From: Ryan Hairyes [EMAIL PROTECTED] To: Peter Werner [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, July 11, 2002 9:45 AM Subject: RE: mod_perl help Thanks for the reply. Actually ... according to sunfreeware perl5.6.1 was compiled with gcc. Anything else you can think of? Thanks again. Quoting Peter Werner [EMAIL PROTECTED]: : you will have to compile perl from scratch as the sunfreeware perl is : compiled with suns compiler not gcc and this causes problems. poke around : sunfreeware.com for the instructions he used to build perl, it is quite : simple. : : -pete : : -Original Message- : From: Ryan Hairyes [mailto:[EMAIL PROTECTED]] : Sent: Thursday, July 11, 2002 4:34 PM : To: [EMAIL PROTECTED] : Subject: mod_perl help : : : Hello all, : : I just compiled mod_perl 1.27 with apache 1.3 for Solaris 8. I used perl : 5.6.1 and gcc from www.sunfreeware.com. After I compiled everything and : tried : to load the perl module (with LoadModule) I receive the following error: : : : Cannot load /usr/local/apache/libexec/libperl.so into server: ld.so.1: : /usr/local/apache/sbin/httpd: fatal: relocation error: file : /usr/local/apache/libexec/libperl.so: symbol main: referenced symbol not : found : : : Any idea on what I did wrong? Thanks. : : Ryan : -- Ryan Hairyes Network/System Administration Lee County School System Phone:919.774.6226 x 1252 Voicemail:x 2361
Re: Can't set multiple cookies?
Last confirmation: 1.3.25-dev does indeed work fine. I've got cookies flying everywhere! Thanks guys! -klm. - Original Message - From: Ken Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 07, 2002 3:45 PM Subject: RE: Can't set multiple cookies? Yup, just confirmed it. 1.3.20 works fine, but .24 is busted. I'll try the latest CVS version. Thanks guys! -klm. -Original Message- From: Balazs Rauznitz [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 2:48 PM To: Dave Rolsky Cc: Ken Miller; [EMAIL PROTECTED] Subject: Re: Can't set multiple cookies? On Fri, Jun 07, 2002 at 12:32:56PM -0500, Dave Rolsky wrote: On Fri, 7 Jun 2002, Ken Miller wrote: Ok, so continuing down the path of a single sign-on system, I've completed a rough framework, and it works fine. However, I thought it might be nice to segregate the various bits of information into different cookies. Unfortunately, setting multiple cookies doesn't seem to be working. Here are the outbound headers obtained via $r-as_string: Set-Cookie: ACS_UID=miller; path=/ Set-Cookie: ACS_Test=blah; path=/ Set-Cookie: ACS_Ticket=stuff; path=/ on the next request, here's the Cookie header: Cookie: ACS_Ticket=stuff; RC_Creds=miller%2C I suspect you're using a 2-tier Apache setup with Apache 1.3.23 on the frontend, right? This is a bug in mod_proxy with 1.3.23. I _think_ its fixed in 1.3.24. If you're using 1.3.24 try reverting to 1.3.22 (which I know works) and see if that fixes it. 1.3.24 is broken in more than one way; I am using the latest CVS version without problems. Balazs
Can't set multiple cookies?
Ok, so continuing down the path of a single sign-on system, I've completed a
rough framework, and it works fine. However, I thought it might be nice to
segregate the various bits of information into different cookies.
Unfortunately, setting multiple cookies doesn't seem to be working. Here
are the outbound headers obtained via $r-as_string:
Set-Cookie: ACS_UID=miller; path=/
Set-Cookie: ACS_Test=blah; path=/
Set-Cookie: ACS_Ticket=stuff; path=/
on the next request, here's the Cookie header:
Cookie: ACS_Ticket=stuff; RC_Creds=miller%2C
The RC_Creds cookie is set in a callback handler. So, where are the other
two cookies?
I've tried the following incantations:
foreach( [ $cookie_a, $cookie_b, ... ] ) {
$r-err_headers_out-add( 'Set-Cookie', $_ );
}
or
$r-err_header_out( 'Set-Cookie' = $cookie_a );
$r-err_headers_out-add( 'Set-Cookie' = $cookie_b );
or
$r-err_headers_out-add( 'Set-Cookie' = [ $cookie_a, $cookie_b ] );
The outbound headers all look the same, but in each case, only the last
cookie is set. This happens with both Netscape and IE.
The really annoying thing is that this was working at one point: I would set
multiple cookies in one go, and all the cookies would be sent back to the
server on the next invocation.
I've searched the Guide and online, but I've not found any clues as to why
the multiple cookies are NOT being set.
Brain cramp, or something more serious?
-klm.
RE: Can't set multiple cookies?
Yup, just confirmed it. 1.3.20 works fine, but .24 is busted. I'll try the latest CVS version. Thanks guys! -klm. -Original Message- From: Balazs Rauznitz [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 2:48 PM To: Dave Rolsky Cc: Ken Miller; [EMAIL PROTECTED] Subject: Re: Can't set multiple cookies? On Fri, Jun 07, 2002 at 12:32:56PM -0500, Dave Rolsky wrote: On Fri, 7 Jun 2002, Ken Miller wrote: Ok, so continuing down the path of a single sign-on system, I've completed a rough framework, and it works fine. However, I thought it might be nice to segregate the various bits of information into different cookies. Unfortunately, setting multiple cookies doesn't seem to be working. Here are the outbound headers obtained via $r-as_string: Set-Cookie: ACS_UID=miller; path=/ Set-Cookie: ACS_Test=blah; path=/ Set-Cookie: ACS_Ticket=stuff; path=/ on the next request, here's the Cookie header: Cookie: ACS_Ticket=stuff; RC_Creds=miller%2C I suspect you're using a 2-tier Apache setup with Apache 1.3.23 on the frontend, right? This is a bug in mod_proxy with 1.3.23. I _think_ its fixed in 1.3.24. If you're using 1.3.24 try reverting to 1.3.22 (which I know works) and see if that fixes it. 1.3.24 is broken in more than one way; I am using the latest CVS version without problems. Balazs
RE: Doing security for backend applications
Thanks the for info! Where my design was coming from was trying to enforce access control completely outside of application - if a request made it to an application, then the application could be assure that the user was allowed to be there. But I think implementing this would be rather difficult. The solution you suggest is not one I had thought of; I guess letting the application worry about invoking access/authen/authz control is much easier than trying to enforce it at a higher level. All I'll have to do is provide the service (ala Passport) that implements the functionality. Cheers! -klm. -Original Message- From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 4:18 PM To: Ken Miller Cc: Modperl Subject: Re: Doing security for backend applications On Tue, 4 Jun 2002, Ken Miller wrote: [...] So, php application requests would bounce from the proxy server to the mod perl server to the php server. You could also make it so it's only when requests needs to be authenticated they go to the mod_perl server. Something like having the php server forward authentication requests to the mod_perl server; but support the same cookie format would be relatively simple. This is all related to a single sign-on environment - once the user has signed on an encrypted cookie will contain the application security information used to authorize the user int the various applications. at perl.org we have made it so authentication requests gets forwarded, and then we have an internal interface for the various servers can validate and migrate authentication cookies. You should be able to find documentation on how passport.com does it; if nothing else then on the pages where it's described why their implementation was insecure at some point. ;-) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Using apache for access control for third party web apps
The saga continues... I've been tasked with developing a single-signon environment for a suite of web applications, some developed in house, and others obtained from third parties; others are still waiting to be developed. The framework I'm developing will, when a user signs in, end up setting a cookie which contains security credentials that will allow access to various parts of the system. The cookie will be encrypted, or perhaps just contain a session id. I currently use a proxy/app server configuration, with the app server running (what else) mod_perl. I will be adding additional servers to host third party applications, which may or may not be running mod_perl. In one case, I know for sure that one of the additional servers will be running PHP. The framework I'm developing will *only* perform application access control, based on an application tree structure. The access control handler will take the cookie and the security requirements for the portion of the application tree being accessed and determine if access is allowed or not. It's up to the application itself to perform authorization (authentication has already been done if the cookie is present). Since access control is performed in mod_perl, I need the proxy to forward all requests to the mod_perl server. For applications hosted on the same mod_perl instance, access control is easy, since the request will naturally flow from handler to handler. Where I'm having difficulty is figuring out how the mod_perl server will perform access control for third party applications that reside on different servers. I guess what I'm asking is this: How can I configure an apache instance to perform access control, and proxying of the request to another server if the access control says the request is ok? From my reading, mod_proxy will only allow top-level configuration, not Location configuration. Ditto for mod_rewrite. Do I have to implement my own proxying? I would like the end result to be something like this: proxy server -- access control server - application servers where the access control server is a mod_perl server, and an application server is one of either mod_perl or PHP or whatever. Is what I'm suggesting doable, or just plain silly? Is there a better way? Cheers! -klm.
Doing security for backend applications
Let's say I have the following configuration: 1. Front end proxy server (no mod_perl) 2. Back end application server (mod_perl) 3. Back end application server (php) Now, *all* application requests are passed to the mod_perl server (yes, including the php requests). Performing security checks for all the applications on the mod_perl server is easy via a few simple handlers. However, I also want to *transparently* handle high-level application access security for the applications served from the php server using the same perl/db modle I use in the mod perl server. So, php application requests would bounce from the proxy server to the mod perl server to the php server. Is this workable? I currently use mod_rewrite to proxy the requests to the mod_perl server, and I'm assuming I would have to do something similar for the php server. However, I'm not all that sure how to do this, since I don't think mod_rewite will work the way I expect - I need to configure a Location but mod_rewrite doesn't work with Location. Or does it? In case anyone is wondering, I'm working on constructing a dynamic front-end portal that will gate through to various applications, some developed in house, others obtained from third parties - the clients wants to perform a global security check before getting to the application, hence the stuff that I'm creating. This is all related to a single sign-on environment - once the user has signed on an encrypted cookie will contain the application security information used to authorize the user int the various applications. Many thanks! -klm.
Re: AuthzHandler, index.html not being accessed
A note: since cookie is involved, why not to implement all the access/authentication/authurization functions at the access control phase using cookie ? I've got them split out to match the phase in which they'd be invoked. That, and the fact that the access handler will be invoked everywhere, but the authorization handler may be different based on the application being protected. Back to the original problem: it all boils down to the Authz handler. When it's activated via 'require', directory indexes are not generated. Remove the require, and *poof*, you get directory indexes. Peter I've got an interesting problem, related to my development of some Authen/Authz handlers. I have a directory on which I've installed an Access, Authen, and Authz handler: - the Access handler makes sure a cookie exists, and redirects the user to a login page if it doens't. If the cookie does exist, populate $r-connection-user. This works. - Authen handler currently returns OK - it will be used to validate the user as stored in the cookie If I 'require valid-user' in the directory, my authz handler doesn't get invoked, which I expect. However, If I request the directory (ie. /test/) I get a directory listing instead of index.html. If I take out the require, thereby bypassing authen/authz, I get index.html. If I also put in custom 'requires', my authz handler is invoked, and the same thing happens. So, it seems that when OK is returned from an authz handler, the DirectoryIndex is not being read. I've been unsucessful in trying to find a solution. Ideas? -klm. BTW, I understand that what I'm doing does appear to be similar to Apache::AuthCookie, but I have a few different requirements that I need to incorporate
Re: AuthzHandler, index.html not being accessed
That's exactly what I did. When the authz handler is installed, I get the directory listing; when it's uninstalled, I get 'Access Denied due to rule'. In neither instance does index.html get displayed. Very strange. I can code around it by turning off indexes and always referencing index.html, but I'd rather not, since this problem might be masking a greater problem. -klm. - Original Message - From: [EMAIL PROTECTED] To: Ken Miller [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 03, 2002 1:50 PM Subject: Re: AuthzHandler, index.html not being accessed Ken: back to your original problem. Maybe you should disbale the default index list by comment out Options Indexes in your httpd.conf, so as to isolate the problem: if it is authz related or not at all. Peter A note: since cookie is involved, why not to implement all the access/authentication/authurization functions at the access control phase using cookie ? I've got them split out to match the phase in which they'd be invoked. That, and the fact that the access handler will be invoked everywhere, but the authorization handler may be different based on the application being protected. Back to the original problem: it all boils down to the Authz handler. When it's activated via 'require', directory indexes are not generated. Remove the require, and *poof*, you get directory indexes. Peter I've got an interesting problem, related to my development of some Authen/Authz handlers. I have a directory on which I've installed an Access, Authen, and Authz handler: - the Access handler makes sure a cookie exists, and redirects the user to a login page if it doens't. If the cookie does exist, populate $r-connection-user. This works. - Authen handler currently returns OK - it will be used to validate the user as stored in the cookie If I 'require valid-user' in the directory, my authz handler doesn't get invoked, which I expect. However, If I request the directory (ie. /test/) I get a directory listing instead of index.html. If I take out the require, thereby bypassing authen/authz, I get index.html. If I also put in custom 'requires', my authz handler is invoked, and the same thing happens. So, it seems that when OK is returned from an authz handler, the DirectoryIndex is not being read. I've been unsucessful in trying to find a solution. Ideas? -klm. BTW, I understand that what I'm doing does appear to be similar to Apache::AuthCookie, but I have a few different requirements that I need to incorporate
Re: AuthzHandler, index.html not being accessed
I should also mention this: Apache/1.3.23 (Unix) mod_perl/1.26 - Original Message - From: Ken Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 30, 2002 11:12 AM Subject: AuthzHandler, index.html not being accessed I've got an interesting problem, related to my development of some Authen/Authz handlers. I have a directory on which I've installed an Access, Authen, and Authz handler: - the Access handler makes sure a cookie exists, and redirects the user to a login page if it doens't. If the cookie does exist, populate $r-connection-user. This works. - Authen handler currently returns OK - it will be used to validate the user as stored in the cookie If I 'require valid-user' in the directory, my authz handler doesn't get invoked, which I expect. However, If I request the directory (ie. /test/) I get a directory listing instead of index.html. If I take out the require, thereby bypassing authen/authz, I get index.html. If I also put in custom 'requires', my authz handler is invoked, and the same thing happens. So, it seems that when OK is returned from an authz handler, the DirectoryIndex is not being read. I've been unsucessful in trying to find a solution. Ideas? -klm. BTW, I understand that what I'm doing does appear to be similar to Apache::AuthCookie, but I have a few different requirements that I need to incorporate
How to proxy everything except selected urls?
I the past, when I've setup a proxy/app server configuration, it's always been to forward certain url's to the app server, with the rest being processed by the proxy. However, I need to turn this around. I want to pass everything to the app server, except for some url's that point at static content (images, mostly). I initially thought something like this would work: --- ProxyPass On ProxyPass / http://other.server.com:1234/ ProxyPassReverse/ http://other.server.com:1234/ alias /graphics /local/path --- However, /graphics also get's proxied to the app server. This isn't what I want. I don't think mod_proxy can do this; at least it's not clear to me how to if it does support this feature. Would mod_rewrite be a better solution? Match on the URL's that I want processed locally (and stop), else map the url to the app server, and forward the request? What's the best way to do this? (in case you're wondering, the back-end app server will be generating most of the content dynamically; I could just have a set of heavy servers, but I'm trying to offload what I can to a lighter front-end. In the end, however, it may not be worth the effort, since the number of static files will be small compared to the dynamic content...) -klm.
different type of login with Apache::AuthCookie?
We currently use Apache::AuthCookie for authentication/authorization, and it works great. However, we want to make a change to how the login works. In addition to having Apache::AuthCookie intercept requests for URL's that require auth/authz, we would like to provide a signon area on the main page where the user can proactively sign in. Would this be as simple as setting the same cookie (using the same format, obviously) as Apache::Authcookie is looking for when signon occurs on the front page? Or, better still, is there a way using A:A itself to do this? Thanks! -klm.
Request Limiter
There was a module floating around a while back that did request limiting (aDOS preventional tool). I've searched the archives (unsuccessfully), and I was wondering if anyone knows what the heck I'm talking about. I thought it was on Matt Sergeant's web site, but for the life of me I can't remember what the url is. Can someone help? My next question would be, if I can't find the module, is what phase would I place a request limiter? Should it just go at the head of the PerlHandler chain, or earlier in the request phase? (I do have 'the book', but unfortunately, it's elsewhere right now). Thanks! -klm.
RE: [benchmark] DBI/preload (was Re: [RFC] improving memory mapping thru code exercising)
At 11:10 AM 6/6/00 -0400, Geoffrey Young wrote:
-Original Message-
From: Jason Terry [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 06, 2000 10:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [benchmark] DBI/preload (was Re: [RFC] improving memory
mapping thru code exercising)
I just wanted to thank you guys for sending this to the mailing list.
I added these lines to my startup script
use Carp;
CGI-compile(qw(my_common_functions));
DBI-install_driver('mysql');
I tried this in my startup.pl with Oracle, and this is what I got:
DBI handle cleared whilst still active at
/home/cardlock/lib/perl5/site_perl/5.005/sun4-solaris/DBD/Oracle.pm line 82.
dbih_clearcom (h 0x54f978, com 0x3319e8):
FLAGS 0x211: COMSET Warn AutoCommit
TYPE 1
PARENT undef
KIDS 0 (0 active)
IMP_DATA undef in 'DBD::Oracle::dr'
I tried both
use DBD::Oracle
and
DBI-install_driver( 'Oracle' );
with the same results. It didn't seem to cause any problems, since
everything still worked.
Something to worry about?
Cheers!
-klm.
---
Ken Miller, Consultant
Shetland Software Services Inc.
Re: Data structure question
At 12:39 PM 6/6/00 -0400, Drew Taylor wrote:
Hello,
This doesn't directly relate to mod_perl, but I'd like to make this as
memory efficient as possible since it runs under mod_perl. :-)
I have a question about data structures. Currently, I am doing SQL
queries and returning an array ref and a hash ref. The array is to
preserve order, and the hash contains various bits of data about that
particular product ( it could be another hash ref, and often is). After
getting the two references, I use foreach to loop through the array, and
within that loop I access various data from the hash where the productID
is the key. It looks like this:
Common.pm:
sub getdata {
my $AR = [123, 456, 243, ... ]
my $HR = { 123 = {foo=bar, name='name', price='123'}, ... }
return ($AR, $HR);
}
Otherstuff.pm:
my ($AR, $HR) = $self-getdata();
foreach (@{$AR}) {
my $name = $HR-{$_}{name};
...
}
I would like to return a single data structure, but order IS important
(hence the current setup). I was thinking of using an array, where each
element is a hash reference. So I would return something like this:
[ {ID=123, name='name123', foor='bar'}, {ID=321, name='name321',
bar='foo'}, ... ]
Well, if the keys are unique, you could just return a hashref, and then
access it using sorted keys:
foreach( sort keys %$HR ) {
## insert useful stuff here
}
Are there any de-referenceing issues (performance wise) that would make
this less efficient than the 2 structures? TIA for any pointers.
Probably not, except your method takes more mems, since you're returning an
extra array. 'Course, the sort takes mems as well, but not as much as the
extra array.
And, there is the overhead of sorting the keys.
I think an array of hashref's is probably the best bet. Then you can use
the DBs sort, and just build the array on the fly, once.
For the site I'm working on, I return a reference to a ResultSet object
which through the next() method returns the next row in the result set:
my $account = $dbs-get_account( "123456789" );
my $rs = $account-get_cards;
while( my $unit = $rs-next ) {
# do something
}
so this enforces the order (due to the order by in the SQL query). This is
a bit slower, since next() returns allocated objects, but it works.
Cheers!
-klm.
-------
Ken Miller, Consultant
Shetland Software Services Inc.
Fine-grained authorization w. Apache::AuthCookie
I'm using Apache::AuthCookie for general authentication/authorization for a site I'm working on. However, there's a requirement for fine-grained authorization down to the page level - a user may have access to most pages in a directory, but be disalllowed access to a single page. Note that the pages in question are in a single directory. What I don't want is to have the user tossed to a login page if they try to access a page for which they have no access, which is what AuthCookie currently does. I thought about chaining an additional authorization handler, but that won't work since if the first one in the chain approves access, then the rest won't be called. I think that AuthCookie should come first, since it verifies that the user has actually logged in. So, if the user passes muster on the first stage of authorization (general access to directory) then any other handlers in the chain won't be called. Or is there a way to override this behaviour? What's the best way to do this? I can always stuff some code into my main handler, but that's ugly. Thanks. Cheers! -klm. --- Ken Miller, Consultant Shetland Software Services Inc.
Re: Access to userland objects in different phases
At 05:28 PM 5/15/00 -0400, you wrote:
I use Class::Singleton in mod_perl apps with *no* problem
whatsoever. In fact, it's pretty nifty to simply say:
my $obj = $class-instance;
anywhere in my application and have the object (whatever it is) simply
pop up.
Well, after looking at the Class::Singleton class, I gave it a shot. After
hacking away at a ChildInitHandler, this is what I ended up with:
package X::Y::Apache::ChildInit;
use strict;
use X::Y::DB::SingletonServices;
use Apache;
##--
-
sub handler
{
my $s = Apache-server;
my $dbs = X::Y::DB::SingletonServices-instance(
{ uri = $s-dir_config( 'DATABASE_URI' ),
userid = $s-dir_config( 'DATABASE_USERID' ),
password = $s-dir_config( 'DATABASE_PASSWORD' ),
options = { AutoCommit = 0,
RaiseError = 1,
PrintError = 0,
ChopBlanks = 1 } } );
$s-log_error( "$$: Services object allocated, handle=$dbs" );
}
1;
Perfect! I now have access to my services object everywhere!
Thanks for the point at Class::Singleton. I would have eventually written
my own, but with CPAN, what's the point?
Cheers!
-klm.
-------
Ken Miller, Consultant
Shetland Software Services Inc.
Access to userland objects in different phases
In the content serving phase I have a Database services object which
manages all access to/from the database. The DB::Services object is
created the first time the handler is hit; the $dbs is made available by
creating a symtab entry, so all my Mason components can get at the database
easily.
I also have a couple of Authen and Authz handlers (ala Apache::AuthCookie),
and I would like to have access to the services object there as well. I
could just create another DB::Services object, but there is quite a bit of
overhead associated with having a Services object in memory, hence I would
like to have a single Services object per Apache process.
Since the auth phases occur before content serving, I would have to create
the DB::Services object in the Auth/Authz handler, and then obtain access
to it in the Mason handler.
So, I think I would do something like this:
Create the DB::Services object in the authentication phase if it hasn't
already been created. (the Services object has to be created in the
auth/authz phase, since that's before the phase in which Mason runs) Once
it's been created, then do something like:
local *HTML::Mason::Commands::dbs = \$dbs;
thus making the DBS available to Mason. By the time the Mason handler
get's invoked, a $dbs is already in the right namespace, and is therefore
ready to use. Any access to $dbs from the actual handler could be obtained
by explicitly referencing the $dbs object via the package global name.
I guess another way of doing it would be to turn the $dbs class into a
Singleton, and provide a class method to get at the instance:
DB::Services-set_uri( 'dbi:Oracle:' );
DB::Services-set_userid( 'foo' );
DB::Services-set_password( 'bar' );
DB::Services-set_options( { ... } );
my $dbs = DB::Services-get_instance;
get_instance() would create the backing object the first time, then
returned the cached object on subsequent calls.
Thoughts?
Cheers!
-klm.
---
Ken Miller, Consultant
Shetland Software Services Inc.
