Re: pulling arguments off rewrite rule
On Tue, Apr 17, 2001 at 09:15:20PM -0400, Christopher Fox wrote:
> I am trying to get the arguments from a referrer off a rewrite rule
>
> here's the deal:
>
> I have a request coming in
>
> http://www.blah.com/index.htm?ref=xxx
>
> I want to pull the ref=xxx and have it follow the user throughout my site
I'm afraid I'm not quite sure what you mean by "have it follow ...
throughout ...".
Do you intend to implement a kind of session management this way?
> I am using a RewriteMap to a program and want to return the QUERY_STRING
> when rewriting the url
>
> so when a user clicks the next page
>
> http://www.blah.com/next.htm
>
> I rewrite it to
>
> http://www.blah.com/next.htm?ref=xxx
>
>
> unfortunately the RewriteMap program is not recognizing the QUERY_STRING and
> returning null
> (i can return a static string no problem)
>
>
> this must be a trivial issue but I am banging my head
it's not as trivial as it might seem, but to get hold of the query string
from within your rewrite map program you could use something like the
following as a workaround:
RewriteEngine On
RewriteMaprwmapprg:/.../rewritemap.pl
RewriteCond %{QUERY_STRING} (.*)
RewriteRule ^(.*)$ ${rwmap:%1##$1}
# or alternatively:
# RewriteRule ^(.*)$ ${rwmap:%{QUERY_STRING}##$1}
rewritemap.pl for example being:
#!/usr/bin/perl
$| = 1; # non-buffered IO
while (<>) {
chomp;
my ($query, $url) = split(/##/, $_, 2);
# for demonstration purposes this changes the query string
# to an uppercase version it...
# (do whatever you need to do here)
print "$url?\U$query\n";
}
The problem basically is that the rewrite map gets started once together
with apache, and its environment is more or less static. Even attempts
to set the QUERY_STRING using the RewriteRule-flag 'E=var:val' have no
effect on the environment of the rewrite map script.
So the workaround is to somehow embed the query string into the string
that's being passed to the map, and split it off there. The seperator
"##" is more or less arbitrary, but you should of course make sure that
it doesn't appear anywhare in the query string itself (although a simple
" " (space) would generally be a reasonable choice, this causes syntactic
problems specifying it in the RewriteRule -- I haven't yet worked out a
way to quote/escape it appropriately).
The above scheme could easily be adapted to various purposes, however,
I'm not quite sure what you want to achieve ultimately. Specifically, I
don't understand who is going to decide which "ref=xxx" string to append
if a request comes in without one... but I guess you know what are doing ;)
Good luck,
Erdmut
--
Erdmut Pfeifer
science+computing ag
-- Bugs come in through open windows. Keep Windows shut! --
Re: Authentication handlers
On Mon, Mar 05, 2001 at 10:28:15AM +1100, Sisyphus wrote: > > > - Original Message - > From: Pierre Phaneuf <[EMAIL PROTECTED]> > To: modperl <[EMAIL PROTECTED]> > Sent: Monday, March 05, 2001 9:29 AM > Subject: Re: Authentication handlers > > > > Cees Hek wrote: > > > > > So instead of storing a y/n in the database, store a unique string that > is > > > used as the realm, and clear it when they log out. Now everytime you > send > > > the Authenitication required header, send the unique realm for this user > > > that you stored in the database, and if it doesn't exist, generate a new > > > one. > > > > Good one! The only bad thing I see is that the realm is visible in the > > dialog box the user see, isn't it? Seeing a random string might be a bit > > unsettling for the user, but there is no technical reason for it not to > > work. > > > > -- > > Pierre Phaneuf > > Systems Exorcist > > Hi, > Are you guys sure about this ? I just tried it out and it doesn't work for > Apache1.3.12(win32) on win 98. > I visited a page in a 'basic authentication' protected directory, then > changed the name of the realm from 'htdocs access' to 'htdocs' but was still > able to access other pages in the same directory without being hit for > username and password. I tried hitting the back button and 'refreshing', and > I also visited another site in the interim. All to no avail. Hi, there are two things to consider here. First, the server really has to send the AUTH_REQUIRED + realm; second, the browser does have to honor that authentication request by asking the user for a new name/password. Typically, servers are set up not to send the AUTH_REQUIRED response code, when the browser already is sending a valid username/password combination. And that's where browser caching comes into play: having queried the user once for username/password, the browser associates it with that specific URL and automatically resends it for each subsequent request to that location (which usually makes sense as it avoids another round trip to the server). Now, what happens if the server is configured such that it sends an AUTH_REQUIRED, even though it did already get the basic authorization header? Well, as so often, it depends on the browser. Netscape, for example, does pop up a dialog box, asking for re-authentication, while IE simply resends the same old username/password combination again. Thus, in IE you don't get a chance to enter any new credentials for a certain location which you've already visited in the current browser session. M$ obviously thought that this would never make sense ;( (it effectively means that you have to restart IE, if you need to login anew...) I haven't yet tested this issue again to see what happens when bringing the "changing realms"-idea into play. Maybe an AUTH_REQUIRED + _new_ realm would even convince IE to allow re-authentication... ;) Erdmut -- Erdmut Pfeifer science+computing gmbh -- Bugs come in through open windows. Keep Windows shut! --
Re: section woe
On Sat, Feb 17, 2001 at 08:56:40PM +1100, Jie Gao wrote:
> Hi All,
>
> P. 417 of Eagle book has this:
>
> Directive is repeated mutiple times
>
> If a directive is repeated multiple times with different arguments each
> time, you can represent it as an array of arrays. This example using
> the AddIcon directive shows how:
>
> @AddIcon = (
> [ '/icons/compressed.gif' => qw(.Z .z .gz .tgz .zip) ],
> [ '/icons/layout.gif' => qw(.html .shtml .htm .pdf) ],
> )
>
> I am testing the limit directives in my section:
>
> %LocationMatch = (
> '^/(myscript|cgi-bin)/' => {
> 'AuthName' => 'Elephant',
> 'AuthType' => 'Animals',
> 'AuthDBMUserFile' => '/mydir/userdbm',
> 'AuthDBMGroupFile' => '/mydir/groupdbm',
> 'PerlAuthenHandler' => 'Animals::ElephantCookieHandler->authen',
> 'PerlSetVar'=> (
> [ 'VirtualServerName' => qw(www.myhouse.org) ],
> [ 'AuthCookieDebug' => 7 ],
>),
syntactically, you need an array reference here, so try using:
'PerlSetVar'=> [
[ 'VirtualServerName' => qw(www.myhouse.org) ],
[ 'AuthCookieDebug' => 7 ],
],
> 'SetHandler'=> 'perl-script',
> 'Options' => '+ExecCGI -Indexes',
> 'PerlSetupEnv' => 'On',
> 'require' => 'valid-user',
> 'AllowOverride' => 'None',
> },
> )
>
Erdmut
--
Erdmut Pfeifer
science+computing gmbh
-- Bugs come in through open windows. Keep Windows shut! --
Re: Slow $r->print
On Mon, Feb 12, 2001 at 01:51:29AM +0100, Alvar Freude wrote: > > > Erdmut Pfeifer schrieb: > > > > I just tried it a couple of times with wget. I always got something > > between 150-190KB/sec -- doesn't seem too slow to me :) > > > > $ wget http://www.assoziations-blaster.de:7000/forum/forum-list_0.html > > --01:15:32-- http://www.assoziations-blaster.de:7000/forum/forum-list_0.html > >=> `forum-list_0.html' > > Connecting to www.assoziations-blaster.de:7000... connected! > > HTTP request sent, awaiting response... 200 OK > > Length: 182,296 [text/html] > > > > 0K -> .. .. .. .. .. [ 28%] > >50K -> .. .. .. .. .. [ 56%] > > 100K -> .. .. .. .. .. [ 84%] > > 150K -> .. .. [100%] > > yes -- but it seems that wget waits for the response before counting ;-) probably yes. > Time taken for tests: 3.266 seconds > Complete requests: 1 > Failed requests:0 > Total transferred: 182634 bytes > HTML transferred: 182296 bytes > Requests per second:0.31 > Transfer rate: 55.92 kb/s received > > > > So, hmmm, this looks like output starts after ~4 seconds ... do you get a high CPU load during those 4 seconds? -- Erdmut Pfeifer science+computing gmbh -- Bugs come in through open windows. Keep Windows shut! --
Re: Slow $r->print
On Mon, Feb 12, 2001 at 12:56:51AM +0100, Alvar Freude wrote:
> Hi,
>
> I recognized, that the output of (my) mod_perl Scripts is very slow, if
> there are longer texts.
>
> I use the following Code on a Linux machine (PII 350, 320 MB), Apache
> 1.3.12, mod_perl 1.23:
>
>
> $r->header_out('Content-Length', length($$textref));
> $r->header_out('Connection', 'close');
> $r->send_http_header;
>
> $r->print($$textref) unless $r->header_only;
> $r->rflush();
>
>
> this tooks for an 200 KByte Text about 4 seconds from localhost, and the
> same as CGI or plain HTML is as fast as expected, so this seems to be an
> mod_perl problem.
>
> If the output is GZIP-Compressed, it is much more faster (also from
> localhost) then uncompressed, despite the extra time for compression.
>
>
> You can check it here:
> http://www.assoziations-blaster.de:7000/forum/forum-list_0.html
I just tried it a couple of times with wget. I always got something
between 150-190KB/sec -- doesn't seem too slow to me :)
$ wget http://www.assoziations-blaster.de:7000/forum/forum-list_0.html
--01:15:32-- http://www.assoziations-blaster.de:7000/forum/forum-list_0.html
=> `forum-list_0.html'
Connecting to www.assoziations-blaster.de:7000... connected!
HTTP request sent, awaiting response... 200 OK
Length: 182,296 [text/html]
0K -> .. .. .. .. .. [ 28%]
50K -> .. .. .. .. .. [ 56%]
100K -> .. .. .. .. .. [ 84%]
150K -> .. .. [100%]
01:15:34 (178.02 KB/s) - `forum-list_0.html' saved [182296/182296]
--
Erdmut Pfeifer
science+computing gmbh
-- Bugs come in through open windows. Keep Windows shut! --
Re: Logging to apache from perl
On Wed, Jan 31, 2001 at 01:18:45AM +, harilaos wrote:
> Hello,
> thanks for the code below. I have put the following into access.conf
>
> PerlAuthenHandler Apache::SillyAuthen;
>
> I copied your code into my modules Apache directory.
> and in cgi-bin i have a script to print all environment variables but
> $remote_user=$ENV{'REMOTE_USER'}; is empty. am i doing anything wrong?
> Also it is for tracking users across my site. So far i am doing it with
> hidden fields, putting session_id in url.
> I thought having a variable following the user without putting all the
> above would
> be easier.
maybe I didn't completely understand what you are trying to achieve, but
before spending too much time on sorting out the technical details of
how to emulate a regular authentication process, I'd rather stick to
the established techniques of user-tracking like
(a) munging session-ids into URLs
(b) cookies
(c) hidden fields (when using forms).
Actually, I don't think that the "REMOTE_USER technique" would work, if
you never let the browser know, that a certain location needs
authentication (and once you let it know, it'll pop up that dialog box).
Normally, the browser "remembers" that a location needs authentication
after having filled in the dialog box the first time. Upon subsequent
requests to the same location, the authentication info automatically
gets resend by the browser. It's not clear to me, how you intend
to emulate that mechanism purely server-side.
Let me know if I misunderstood something...
Erdmut
>
> darren chamberlain wrote:
> >
> > harilaos ([EMAIL PROTECTED]) said something to this effect on 01/30/2001:
> > > I want to create a username and password when a user enters my site,
> > > then pass these values to apache to authenticate. Then i could
> > > have the REMOTE_USER variable available throught the users
> > > stay at my site.
> >
> > You want to create them? Do you mean create a new session for
> > each user? You might want to look into Apache::Session for this;
> > it has a customizable session key generator.
> >
> > Here is a simple example, generating a simple session id. Run this
> > as a PerlAuthenHandler:
> >
> > package Apache::SillyAuthen;
> >
> > use Apache::Constants qw(OK);
> > use MD5;
> >
> > sub handler {
> > my $r = shift;
> >
> > # Make a random "username". This can be a call to any
> > # function, etc, that can generate a username
> > my $session = MD5->hexhash($r->get_remote_host . time . {});
> >
> > # Set the username in the conn_rec
> > $r->connection->user($session);
> >
> > # Set the REMOTE_USER env variable
> > $r->subprocess_env('REMOTE_USER', $session);
> >
> > # Be sure to tell Apache that the authentication handler did
> > # its thing!
> > return OK;
> > }
> >
> > Is that what you mean?
> >
> > (darren)
> >
> > --
> > It's not that things are getting worse, it's just that news reporting is
> > getting better.
--
Erdmut Pfeifer
science+computing gmbh
-- Bugs come in through open windows. Keep Windows shut! --
Re: [BUG] Apache 1.3.14 front-end-back-end weirdness.
On Fri, Dec 08, 2000 at 07:23:08PM +0400, BeerBong wrote:
> Hello!
>
> I tried to migrate to Apache 1.3.14 from 1.3.12 ...
> Heh.
> After recompiling apache and starting the server with the same config get
> 400 Bad request on any request to mod_perl back-end server. Static html and
> images are returned ok.
>
> Some time was spent for hunting the problem.
> Turn on rewriting log with level 9.
>
> RewriteEngine On
> RewriteLogLevel 9
> RewriteLog /var/apache/simple_d/logs/rewrite.log
> RewriteMap ports txt:/usr/local/apache/conf/port_d.map
> RewriteRule ^/(.*\.s?asp)$ http://$host:${ports:%{SERVER_PORT}|8081}/$1
> [P,L]
>
> Request
> /paper/test.asp
> translated to
> http://www.samara.ru:|8081}/paper/test.asp
>
> It seems that mod_rewrite processes nested back references not correctly.
> Just meets first closing brace and consider it as back reference.
Hello,
I observed the same problem with nested ${}/%{} statements such as
RewriteMap actrlprg:/usr/local/apache-1.3.12/bin/rewrite-map.pl
RewriteRule ^/(ac-)?adm/?(.*)$ ${actrl:%{HTTP:Authorization}#a#/ac-adm/$2} [PT,L]
(... -- details irrelevant here) ^
what seems to be causing the problem is that the brace directly
following "Authorization" is interpreted as the closing brace for "${"
instead of "%{".
>From a quick glance at the code I would say that the strchr() in line 2261
of rewrite.c (the one distributed with 1.3.14) is responsible for this...
I don't know if nested statements such as these are by intention no
longer supported since the recent security-related patch (?)
Perhaps someone more knowledgable could comment on this -- thanks!
--
Erdmut Pfeifer
science+computing gmbh
-- Bugs come in through open windows. Keep Windows shut! --
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
