Re: session expiration
On Mon, 20 Nov 2000, Bill Moseley wrote: > At 03:00 PM 11/20/00 -0600, Trey Connell wrote: > >Is there anyway to know that a user has disconnected from their session > >through network failure, power off, or browser closure? > > How is that different from just going out for a cup of coffee or opening a > new browser window and looking at a different site? > > >I am logging > >information about the user to a database when they login to a site, and > >I need to clean up this data when they leave. > > Define "leave" and you will have the answer. > > All you can do is set an inactivity timeout, I'd suspect. cron is your > friend in these cases. And spec out what you want when a user does happen to come back after you have expired their session with cron. (they leave their browser open for awhile, or they bookmark a page). -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how do I store/retrieve a hash through Apache::Session?
On Fri, 3 Nov 2000, Enrique I.Rodriguez wrote:
> Maybe a silly question...
>
> how do I store/retrieve a hash through Apache::Session?
store hash references, not hashes.
>
> This doesn't work...
> # retrieve
> %table=$session{table};
$tableref = $session{table};
> ...
> # store
> $session{table}=%table;
$session{table}= \%table;
or, preferably:
my $tableref = {};
# add stuff to table
# ...
$session{table}= $tableref;
>
> What's my fault?
>
Re: Forking in mod_perl?
On Thu, 5 Oct 2000, Sean D. Cook wrote: > > On Wed, Oct 04, 2000 at 02:42:50PM -0700, David E. Wheeler wrote: > > > Yeah, I was thinking something along these lines. Don't know if I need > > > something as complex as IPC. I was thinking of perhaps a second Apache > > > server set up just to handle long-term processing. Then the first server > > > could send a request to the second with the commands it needs to execute > > > in a header. The second server processes those commands independantly of > > > the first server, which then returns data to the browser. > > > > In a pinch, I'd just use something like a 'queue' directory. In other > > words, when your mod_perl code gets some info to process, it writes > > this into a file in a certain directory (name it with a timestamp / > > cksum to ensure the filename is unique). Every X seconds, have a > > It might be safer to do this in a db rather than the file system. That > way there is less chance for colision and you don't have to worry about > the file being half written when the daemon comes along and tries to read > the file while mod_perl/apache is trying to write it. Let the DB do the > storage side and let the damon do a select to gather the info. If you don't have a db easily available, I've had good luck using temp files. You can avoid partially written file errors by exploiting the atomic nature of moving (renaming) files. NFS does *not* have this nice behavior, however. -Tim
Re: SELECT cacheing
On Fri, 8 Sep 2000, Perrin Harkins wrote: > On Fri, 8 Sep 2000, Roger Espel Llima wrote: > > > - If possible, use some existing cache module for the storage, like > > > Apache::Session or one of the m/Cache/ modules on CPAN. > > > > Others have suggested Storable. I've used this one before, and I can > > agree that it's probably a good solution. > > Storable is just a way to turn a complex data structure into a single > scalar. You still need to handle the file manipulation yourself. Most of > the existing cache modules use Storable to serialize to a scalar and then > files or shared memory or a dbm for actual storage. I would delegate the tieing, serialization, and locking to a module like Apache::Session (It uses Storable internally). Then the user can specify their own favorite backing store and locking mechanism by subclassing Apache::Session. I would also look to the Memoize module for ideas: http://search.cpan.org/search?dist=Memoize -Tim
[Mason]Re: how to check for ssl.
On Thu, 3 Aug 2000, Stas Bekman wrote:
> On Thu, 3 Aug 2000, ___cliff rayman___ wrote:
>
> > use Apache::URI ();
> > $r->parsed_uri->scheme;
> >
> > returns http or https
>
> Not really, you can spoof both:
> http://thingy.kcilink.com/modperlguide/config/Knowing_the_proxy_pass_ed_Connec.html
>
> > [EMAIL PROTECTED] wrote:
> >
> > > I've got a section of our site where I want to force the user to
> > > connect via ssl.
> > > Inside of mod_perl, is there a parameter I can grab to see whether
> > > the connection is ssl or not? Or a way to get the port number?
> > >
> > > Scott
I had the same problem recently, where the mod_perl backend server did not
know what was happening on the front end with respect to SSL. I solved it
in a way that is flexible, but perhaps overkill:
I patched mod_headers.c on the frontend server to allow one to attach
extra headers to requests when they are proxied to the backend. This
allows you to stuff info in headers about SSL, or the remote-ip, etc.
You can specify headers to set with the same substitution syntax as
RewriteRule
(The patch is attached)
example:
On the front-end server:
( cd apache_1.3.12 ; patch -p1
SSLOptions StdEnvVars
ProxyHeaderRewrite append X-SSL-Cipher "%{ENV:SSL_PROTOCOL} ${ENV:SSL_CIPHER}"
# tell upstream server the virtual host used
ProxyHeaderRewrite append X-Frontend-Host "%{HTTP:Host}"
Now, for a typical SSL request that is proxied to the back end (as
plaintext), these headers are added:
X-Forwarded-For: 1.2.3.4
X-Frontend-Host: my.frontend.site.com
X-SSL-Cipher: SSLv3 IDEA
On the backend server, parse the headers with some little perl handler in
startup.pl, and stuff the info where most other modules expect it (in $r,
or in environment vars):
sub My::ProxyHeaderParse ($) {
my $r = shift;
# we'll only look at the X-Forwarded-For header if the requests
# comes from our local network
return OK unless ($r->connection->remote_ip =~ /^192\.168/ );
if (my ($ip) = $r->header_in('X-Forwarded-For') =~ /([^,\s]+)$/) {
$r->connection->remote_ip($ip);
}
# mv X-Frontend-Host: into Host: header
my $host_header = $r->header_in('X-Frontend-Host');
if ( defined($host_header) ) {
$r->header_in('Host', $host_header)
}
# set up ssl env vars, if present in a X-SSL-Cipher header
my $ssl_header = $r->header_in('X-SSL-Cipher');
if ( defined($ssl_header) ) {
($ENV{SSL_PROTOCOL}, $ENV{SSL_CIPHER}) = split(/ /,$ssl_header);
$ENV{HTTPS} = 'ON'; # CGI.pm:protocol() require 'ON' (not 1 !)
}
return OK;
}
# called in httpd.conf
# PerlPostReadRequestHandler My::ProxyHeaderParse
--- apache_1.3.12.dist/src/modules/standard/mod_headers.c Wed Oct 27 02:26:53
1999
+++ apache_1.3.12/src/modules/standard/mod_headers.cThu Jul 13 16:53:11 2000
@@ -99,9 +99,52 @@
* To remove a header:
* Header unset Author
*
+ *
+ * Non-standard Additions:
+ *
+ *Most code is from mod_rewrite, by
+ * Ralf S. Engelschall
+ * [EMAIL PROTECTED]
+ *Assembled by Tim Bishop <[EMAIL PROTECTED]>
+ *
+ *
+ * HeaderRewrite (set headers to client using RewriteCond syntax)
+ *
+ * Syntax: HeaderRewrite action header rewriteValue
+ *
+ * This works the same as the header directive, except that full
+ * mod_rewrite RewriteCond interpolation is performed on the rewriteValue
+ * string. See http://www.apache.org/docs/mod/mod_rewrite.html#RewriteCond
+ * (Of course, back-references (%N, $N) have no meaning)
+ *
+ *
+ * ProxyHeaderRewrite (set headers sent to upstream servers (if proxying))
+ *
+ * Syntax: ProxyHeaderRewrite action header rewriteValue
+ *
+ * ProxyHeaderRewrite allows you to rewrite headers sent to upstream
+ * servers when your server is functioning as a proxy server.
+ * This is useful when you want to send additional header information
+ * to upstream servers.
+ *
+ * Bugs: Cannot rewrite the Host header with ProxyHeaderRewrite
+ *
+ * Examples:
+ *
+ *# tell upstream server the ip of the request
+ *ProxyHeaderRewrite append X-Forwarded-For "%{REMOTE_ADDR}"
+ *# tell upstream server info on SSL status
+ *
+ *SSLOptions StdEnvVars
+ *ProxyHeaderRewrite append X-SSL-Cipher "%{ENV:SSL_PROTOCOL}
+%{ENV:SSL_CIPHER}"
+ *
+ *# tell upstream server the virtual host used
+ *ProxyHeaderRewrite append X-Frontend-Host "%{HTTP:Host}"
+ *
*/
#include "httpd.h"
+#include "http_log.h"
#include "http_config.h"
typedef enum {
@@ -111,12 +154,50 @@
hdr_unset = &#x
Re: using a 3-tier mod_perl setup
On Sun, 16 Jul 2000, Gunther Birznieks wrote:
> Is any of this header rewriting already on Ralf's TODO list for mod_rewrite?
>
> Does it make sense to make mod_headers more complex? Or to add these
> features to mod_rewrite already?
>
> Just throwing the idea out there.
>
> This is an interesting module though.
>
I considered adding the ProxyHeaderRewrite and HeaderRewrite commands to
mod_rewrite, but I felt more comfortable mucking around in the much
simpler mod_headers. I'm not happy that I had to duplicate some code from
mod_rewrite, tho.
I did not find any TODO lists for mod_rewrite.
BTW, I have attached a newer patch for mod_headers, which fixes a bug of
mine with ProxyHeaderRewrite unset. (apply to a stock 1.3.12 mod_headers)
I'm glad you find it interesting - this is my first public module
contribution.
-Tim
-
(from my original post)
The attached patch
(cd apache_1.3.XX; patch -p1 < ProxyHeaderRewrite.p2.patch; make
install)
will add two commands to mod_headers:
HeaderRewrite - dynamically set headers for the client
ProxyHeaderRewrite - dynamically set headers for the upstream proxy
server
While the original mod_headers would allow you so say:
Header append Foo "burfl"
Now you can say
HeaderRewrite append Foo "%{ENV:BURFL}", using the full RewriteCond syntax
My current lightweight apache server config looks something like:
ProxyHeaderRewrite append X-Forwarded-For "%{REMOTE_ADDR}"
ProxyHeaderRewrite append X-Frontend-Host "%{HTTP_HOST}"
...
SSLOptions StdEnvVars
ProxyHeaderRewrite append X-SSL-Cipher "%{ENV:SSL_PROTOCOL}
%{ENV:SSL_CIPHER}"
--- apache_1.3.12.dist/src/modules/standard/mod_headers.c Wed Oct 27 02:26:53
1999
+++ apache_1.3.12/src/modules/standard/mod_headers.cThu Jul 13 16:53:11 2000
@@ -99,9 +99,52 @@
* To remove a header:
* Header unset Author
*
+ *
+ * Non-standard Additions:
+ *
+ *Most code is from mod_rewrite, by
+ * Ralf S. Engelschall
+ * [EMAIL PROTECTED]
+ *Assembled by Tim Bishop <[EMAIL PROTECTED]>
+ *
+ *
+ * HeaderRewrite (set headers to client using RewriteCond syntax)
+ *
+ * Syntax: HeaderRewrite action header rewriteValue
+ *
+ * This works the same as the header directive, except that full
+ * mod_rewrite RewriteCond interpolation is performed on the rewriteValue
+ * string. See http://www.apache.org/docs/mod/mod_rewrite.html#RewriteCond
+ * (Of course, back-references (%N, $N) have no meaning)
+ *
+ *
+ * ProxyHeaderRewrite (set headers sent to upstream servers (if proxying))
+ *
+ * Syntax: ProxyHeaderRewrite action header rewriteValue
+ *
+ * ProxyHeaderRewrite allows you to rewrite headers sent to upstream
+ * servers when your server is functioning as a proxy server.
+ * This is useful when you want to send additional header information
+ * to upstream servers.
+ *
+ * Bugs: Cannot rewrite the Host header with ProxyHeaderRewrite
+ *
+ * Examples:
+ *
+ *# tell upstream server the ip of the request
+ *ProxyHeaderRewrite append X-Forwarded-For "%{REMOTE_ADDR}"
+ *# tell upstream server info on SSL status
+ *
+ *SSLOptions StdEnvVars
+ *ProxyHeaderRewrite append X-SSL-Cipher "%{ENV:SSL_PROTOCOL}
+%{ENV:SSL_CIPHER}"
+ *
+ *# tell upstream server the virtual host used
+ *ProxyHeaderRewrite append X-Frontend-Host "%{HTTP:Host}"
+ *
*/
#include "httpd.h"
+#include "http_log.h"
#include "http_config.h"
typedef enum {
@@ -111,12 +154,50 @@
hdr_unset = 'u' /* unset header */
} hdr_actions;
+typedef enum {
+ hdr_string = 's', /* header is a string */
+ hdr_env_var = 'v', /* set header from env var */
+ hdr_interpolate = 'i' /* header needs to be interpolated (not yet!) */
+} hdr_value_type;
+
+typedef enum {
+ hdr_client = 'c', /* modify headers for client */
+ hdr_upstream = 'u'/* modify headers for upstream server */
+} hdr_header_target;
+
typedef struct {
-hdr_actions action;
-char *header;
-char *value;
+ hdr_actions action;
+ char *header;
+ char *value;
+ hdr_value_type value_type;
+ hdr_header_target header_target; /* one of hdr_client | hdr_upstream */
} header_entry;
+
+/* env variable interpolation support */
+static void expand_variables_inbuffer(request_rec *r, char *buf, int buf_len);
+static char *expand_variables(request_rec *r, char *str);
+static char *lookup_variable(request_rec *r, char *var);
+static char *lookup_header(request_rec *r, const char *name);
+
+#ifndef LONG_STRING_LEN
+#define LONG_STRING_LEN 20
using a 3-tier mod_perl setup
I am running a 3-tier mod_perl setup as advised by the Guide:
Lightweight apache <-> mod_perl apache <-> db server.
One of the problems with this setup is that the mod_perl apache no longer
knows some details about the client request, like the client IP.
I used Ask Bjoern Hansen's module proxy_add_forward, which adds a
"X-Forwarded-For" header to to the request as it is forwarded to the
mod_perl apache server.
After I added SSL to my lightweight (but gaining!) apache, I found
I needed some SSL connection information on the mod_perl server as well.
I recently fell in love with mod_rewrite, and so I ported some of its
capabilities to mod_headers
The attached patch
(cd apache_1.3.XX; patch -p1 < ProxyHeaderRewrite.patch; make install)
will add two commands to mod_headers:
HeaderRewrite - dynamically set headers for the client
ProxyHeaderRewrite - dynamically set headers for the upstream proxy server
While the original mod_headers would allow you so say:
Header append Foo "burfl"
Now you can say
HeaderRewrite append Foo "%{ENV:BURFL}", using the full RewriteCond syntax
My current lightweight apache server config looks something like:
ProxyHeaderRewrite append X-Forwarded-For "%{REMOTE_ADDR}"
ProxyHeaderRewrite append X-Frontend-Host "%{HTTP_HOST}"
...
SSLOptions StdEnvVars
ProxyHeaderRewrite append X-SSL-Cipher "%{ENV:SSL_PROTOCOL} %{ENV:SSL_CIPHER}"
Did I miss another way to do this? Is this patch useful?
BTW,
the Guide on server architecture:
http://perl.apache.org/guide/strategy.html
Ask Bjoern Hansen's module proxy_add_forward
http://www.cpan.org/authors/id/ABH/mod_proxy_add_forward.c
-Tim
--- apache_1.3.12.dist/src/modules/standard/mod_headers.c Wed Oct 27 09:26:53
1999
+++ apache_1.3.12/src/modules/standard/mod_headers.cTue Jul 11 00:38:26 2000
@@ -99,9 +99,52 @@
* To remove a header:
* Header unset Author
*
+ *
+ * Non-standard Additions:
+ *
+ *Most code is from mod_rewrite, by
+ * Ralf S. Engelschall
+ * [EMAIL PROTECTED]
+ *Assembled by Tim Bishop <[EMAIL PROTECTED]>
+ *
+ *
+ * HeaderRewrite (set headers to client using RewriteCond syntax)
+ *
+ * Syntax: HeaderRewrite action header rewriteValue
+ *
+ * This works the same as the header directive, except that full
+ * mod_rewrite RewriteCond interpolation is performed on the rewriteValue
+ * string. See http://www.apache.org/docs/mod/mod_rewrite.html#RewriteCond
+ * (Of course, back-references (%N, $N) have no meaning)
+ *
+ *
+ * ProxyHeaderRewrite (set headers sent to upstream servers (if proxying))
+ *
+ * Syntax: ProxyHeaderRewrite action header rewriteValue
+ *
+ * ProxyHeaderRewrite allows you to rewrite headers sent to upstream
+ * servers when your server is functioning as a proxy server.
+ * This is useful when you want to send additional header information
+ * to upstream servers.
+ *
+ * Bugs: Cannot rewrite the Host header with ProxyHeaderRewrite
+ *
+ * Examples:
+ *
+ *# tell upstream server the ip of the request
+ *ProxyHeaderRewrite append X-Forwarded-For "%{REMOTE_ADDR}"
+ *# tell upstream server info on SSL status
+ *
+ *SSLOptions StdEnvVars
+ *ProxyHeaderRewrite append X-SSL-Cipher "%{ENV:SSL_PROTOCOL}
+%{ENV:SSL_CIPHER}"
+ *
+ *# tell upstream server the virtual host used
+ *ProxyHeaderRewrite append X-Frontend-Host "%{HTTP:Host}"
+ *
*/
#include "httpd.h"
+#include "http_log.h"
#include "http_config.h"
typedef enum {
@@ -111,12 +154,50 @@
hdr_unset = 'u' /* unset header */
} hdr_actions;
+typedef enum {
+ hdr_string = 's', /* header is a string */
+ hdr_env_var = 'v', /* set header from env var */
+ hdr_interpolate = 'i' /* header needs to be interpolated (not yet!) */
+} hdr_value_type;
+
+typedef enum {
+ hdr_client = 'c', /* modify headers for client */
+ hdr_upstream = 'u'/* modify headers for upstream server */
+} hdr_header_target;
+
typedef struct {
-hdr_actions action;
-char *header;
-char *value;
+ hdr_actions action;
+ char *header;
+ char *value;
+ hdr_value_type value_type;
+ hdr_header_target header_target; /* one of hdr_client | hdr_upstream */
} header_entry;
+
+/* env variable interpolation support */
+static void expand_variables_inbuffer(request_rec *r, char *buf, int buf_len);
+static char *expand_variables(request_rec *r, char *str);
+static char *lookup_variable(request_rec *r, char *var);
+static char *lookup_header(request_rec *r, const char *name);
+
+#ifndef LONG_STRING_LEN
+#define LONG_STRING_LEN 2048
+#endi
Re: proxy requests via mod_proxy
Kip says:
>
> I currently use a module written by Ask Bjoern Hansen called
> proxy_add_forward.
>
> Compiling this into your proxy server adds an X-Forwarded-For header to the
> proxy requests which contains the ip of the client you're interested in.
>
> You can find that module here
>
> http://modules.apache.org/search?id=124
>
> and probably a host of other places.
Dave-
Here's a copy of my specific instructions on adding IP logging to the
app server:
In mod_perl dir:
perl Makefile.PL \
APACHE_SRC=../apache_1.3.12/src \
DO_HTTPD=1 \
USE_APACI=1 \
PREP_HTTPD=1 \
EVERYTHING=1
copy mod_proxy_add_forward.c to apache_1.3.12/ dir
in apache_1.3.12 dir:
OPTIM="-O3 -m486" \
./configure --prefix=/usr \
--with-layout=RedHat \
--add-module=mod_bandwidth.c \
--add-module=mod_proxy_add_forward.c \
--enable-module=most \
--enable-shared=max \
--disable-rule=WANTHSREGEX \
--disable-module=auth_dbm \
--disable-module=auth_db \
--activate-module=src/modules/perl/libperl.a \
--with-perl=/usr/bin/perl
(notice the --add-module=mod_proxy_add_forward.c line)
(you probably don't want all of the other lines)
In the httpd.conf for the proxy server:
(add at the end of LoadModule statements:)
LoadModule proxy_add_forward_module modules/mod_proxy_add_forward.so
(add at the end of the AddModule statements:)
AddModule mod_proxy_add_forward.c
now your proxy server will send the X-Forwarded-For header. But the app
server needs to take that header and treat it as the originating ip.
In the startup.pl of the app server:
sub My::ProxyRemoteAddr ($) {
my $r = shift;
if (my ($ip) = $r->header_in('X-Forwarded-For') =~ /([^,\s]+)$/) {
$r->connection->remote_ip($ip);
}
return OK;
}
and in your httpd.conf file, somewhere:
# move X-Forwarded-For ip into r->connection->remote_ip
PerlPostReadRequestHandler My::ProxyRemoteAddr
-Tim
Re: growing processes
> You're probably doing something that is causing certain variables to have > temporarily large values. As always, start with the guide: > > http://perl.apache.org/guide/performance.html#Memory_leakage > > You should also make sure you're doing the usual pre-loading and other > suggestions from this section of the guide. You may find the section in > the camel book on optimizing for size useful as well. > > -Perrin The issue of growing (but never shrinking) processes comes up frequently. I saw a nice explanation of why perl can not return memory no longer needed in the Perl Cookbook: Freed memory is returned to Perl for later use, but few operating systems reclaim it and decrease the process's memory footprint. This is because most memory allocators use a stack, and if you free up memory in the middle of the stack, the operating system can't take it back without moving the rest of the allocated memory around. That would destroy the integrity of your pointers and blow XS code out of the water. http://www.oreilly.com/catalog/cookbook/ Slightly related: Is it possible/desirable to have to have perl allocate memory in a certain range? Perhaps within a previously allocated shared mem area? Assuming you delt with the locking issues, it seems that you could share one "scratch" space among a number of processes. -Tim
Re: crypt() under windows
Hi- We used Martin Vorlaender's Crypt::UnixCrypt module for the same reason you need it - no crypt() on Windows. http://search.cpan.org/search?dist=Crypt-UnixCrypt However we discovered that it is not *exactly* the same as linux crypt(). That is, for some passwords that contained non-alphanumerics in the first 2 character positions, the hash produced by Crypt::UnixCrypt and linux's crypt() differed. If you just need something that works similarly to crypt on windows, this module works well. But don't use it if you need the hashes to be portable. -Tim On Wed, 19 Apr 2000, indrek siitan wrote: > Hi, > > seems like the standard crypt() function is not implemented > under Windows. :( > > does anyone have a perl source, that does the 3DES crypt() > encryption? i only need it for a development version, so the > speed doesn't matter. the production version will run under > Linux and use the standard crypt() call. > > > Rgds, > Tfr > > --==< [EMAIL PROTECTED] >==< http://tfr.cafe.ee/ >==< +1-504-4467425 >==-- >
