silly CGI::Cookie bug/frustrations
Hi all,
I've spent the last couple hours trying to debug a seemingly simple
piece of code. I've come up with something that seems puzzling (but it's
probably just too early in the morning for me) -- any clarification
would be appreciated.
The code I'm writing is a cookie-based authentication scheme, inspired
by Apache::TicketAccess from the Eagle book (thanks Doug Lincoln!).
I'm sending the client the ticket cookie like so:
use constant TICKET_NAME = 'AdminTicket';
# ... lots of code
my $ticket = CGI::Cookie-new(-name = TICKET_NAME,
-path = '/'
# more stuff
);
$r-header_out('Set-Cookie' = $ticket);
Now, this seems to work fine. The browser is sent a cookie, and sends it
back to the server when it requests a page that requires authentication.
However, I can't seem to verify the cookie properly. Here's my
verification code:
sub verify_ticket {
my $self = shift;
my $r = $self-{_req};
print STDERR Cookie: . $r-header_in('Cookie') . \n; #DEBUG
my %cookies = CGI::Cookie-parse($r-header_in('Cookie'));
return (0, 'user has no cookies') unless %cookies;
#DEBUG
my $cookie_name;
foreach (keys %cookies) {
print STDERR Cookie: [$_] - [$cookies{$_}]\n;
print STDERR Cookie name: [$_] ; Expected: [ . TICKET_NAME .
]\n;
print STDERR The cookies match.\n if $_ eq TICKET_NAME;
$cookie_name = $_; # HACK: remember a valid hash key
}
# this does NOT work
#return (0, 'user has no ticket') unless $cookies{TICKET_NAME};
# this works, strangely
return (0, 'user has no ticket') unless $cookies{$cookie_name};
# lots more code
}
(As you can tell, I've been banging my head against the wall for a
while, inserting print statements ;-) ).
I get the following log output:
Cookie:
AdminTicket=ip127.0.0.1expires15hashf6o%2BtYJ2AFm1aBy3plFrOigo1ygusernconwaytime1010403781
Cookie: [AdminTicket] -
[AdminTicket=ip127.0.0.1expires15hashf6o%2BtYJ2AFm1aBy3plFrOigo1ygusernconwaytime1010403781;
path=/]
Cookie name: [AdminTicket] ; Expected: [AdminTicket]
The cookies match.
Now, this is as I expected it. However, the commented out code such as:
return (0, 'user has no ticket') unless $cookies{TICKET_NAME};
Doesn't work -- it seems to think that there is no such hash element as
TICKET_NAME.
Since there is only 1 cookie, I used the ugly hack above and iterated
through the keys of the hash and used the only actual hash element. The
weird that is that the value I get from this is 'eq' to TICKET_NAME --
yet, it works, but TICKET_NAME does not. IIRC, if I replace the
instances of TICKET_NAME with its literal value ('AdminTicket'), it also
does not work.
Would someone be kind enough to point out what I've missed? Because I'm
stumped...
Thanks in advance,
Neil
--
Neil Conway [EMAIL PROTECTED]
PGP Key ID: DB3C29FC
Lightweight CGI.pm for PerlHandlers
Hi all, I'd like to be able to use something similar to CGI.pm's HTML generation methods in a PerlHandler I'm writing. Since I'm not ever going to be using CGI directly (and also, the HTML I'm doing is pretty simple), CGI.pm seems like overkill -- and from looking at some basic memory usage data, it seems like you pay for this complexity/flexibility. Is there a simple (fast, light) module that generates HTML in a similar style to CGI.pm, for use with mod_perl? At the moment, I'd rather not move to a system like HTML::Mason or Template Toolkit -- the HTML I'm producing is very simple (in fact, I've just been using $r-print up to now, and it's not _too_ bad). Thanks for any suggestions, Neil
dynamic vs. mostly static data
I'm writing a web app in mod_perl, using a PostgreSQL database backend and HTML::Template. In looking for ways to optimize performance, I noticed that although my code is doing several (say, 4-5) database queries per handler/webpage, a large part of the data (~2 queries) is mostly static (it will change perhaps once per week, or once per month). It's obviously inefficient to run these queries on the database for every single request. How can I 'cache' this data so that all Apache children can access it quickly? Is there a way to automatically update this cache periodically (say every 10 minutes)? Also, this solution should work on any reasonably modern UNIX system (Win32 is not important for now). I couldn't find this anywhere, but if someone tells me where, I'd be happy to RTFM. Ask me if you need more info. TIA, Neil -- Neil Conway [EMAIL PROTECTED] Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc Encrypted mail welcomed "The superior man understands what is right; the inferior man understands what will sell." -- Confucius
Re: can I close the client connection but keep a script running?
On Fri, Oct 13, 2000 at 07:15:30PM -0400, Shimon Rura wrote:
I'd like to be able to tell apache to close off its connection with the
client but leave the script running. An example use would be for the client
to start a time-consuming job on the web server, and let it run without
subjecting them to a spinning wait icon for 10 minutes.
This has been discussed in detail by the list recently. The solution
you describe ('closing the connection to the client') is not ideal
because it wastes 1 Apache child, which sits idle while it waits for
the Perl script to complete. I think the consensus was that the best
solution is to pass the request to an external program (possibly a
daemon) through some method (RPC, 'queue' directory or DB table, etc),
and then let the external program perform the time consuming task,
while the mod_perl script returns the data to the client like normal.
If I've got something wrong, sorry - check one of the archives for
extensive discussion.
HTH,
Neil
--
Neil Conway [EMAIL PROTECTED]
Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc
Encrypted mail welcomed
Is uniformity [of religion] attainable? Millions of innocent men,
women, and children, since the introduction of Christianity, have
been burnt, tortured, fined, imprisoned; yet we have not advanced
one inch towards uniformity.
-- Thomas Jefferson, "Notes on Virginia"
PGP signature
Re: Forking in mod_perl?
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 daemon poll the directory; if it finds a file, it processes it. If not, it goes back to sleep for X seconds. I guess it's poor man's IPC. But it runs over NFS nicely, it's *very* simple, it's portable, and I've never needed anything more complex. You also don't need to fork the daemon or startup a new script every processing request. But if you need to do the processing in realtime, waiting up to X seconds for the results might be unacceptable. How does this sound? HTH, Neil -- Neil Conway [EMAIL PROTECTED] Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc Encrypted mail welcomed It is dangerous to be right when the government is wrong. -- Voltaire PGP signature
Re: Where's the filehandle in a PerlHandler module?
On Wed, Sep 27, 2000 at 04:12:23PM -0700, Clayton Mitchell wrote:
In a handler I want to process all requests and parse the document
requested and spit it out after marking it up.
I have put in place this code, but I don't see how to access the actual
requested document.
I'm hoping there's already an open filehandle to it somewhere?
There's no open filehandle because the file the HTTP client thinks it's
requesting may not actually exist. For example:
Location /foo
SetHandler perl-script
PerlHandler Foo::Bar::Baz
/Location
There isn't necessarily a file/directory ${DOCUMENT_ROOT}/foo - the request
is intercepted by mod_perl before it reaches that state.
There are several different methods for looking at and parsing the request
URI. The one that seems right for you is $r-filename()
BTW, this is documented in `perldoc Apache`. Another useful reference is
the mod_perl reference card.
HTH,
Neil
--
Neil Conway [EMAIL PROTECTED]
Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc
Encrypted mail welcomed
Violence is to dictatorship as propaganda is to democracy.
-- Noam Chomsky
PGP signature
persistent info (storing config?)
(I'm not subscribed, please CC: [EMAIL PROTECTED]) Hello everyone. I'm using mod_perl and Apache for a typical web project. Each piece of mod_perl code will need to be able to access a lot of configuration info. I guess we'll store the configuration info in a plaintext file. This configuration info will need to be changed by the admin (whether by editing the config file or using a web interface). However, I'd rather not parse the entire config file for every single request (the config file may be very long, and/or consist of multiple files). Is there any way to parse the config file once, store the results, and make the data available to any of my code? I was thinking of putting the parsing code into a Perl module, and `use`ing the module in startup.pl . But will this ensure that the file is only parsed once? When subsequent scripts 'use' the module, won't this require parsing the file again? Or if the parsing of the file is separated into a subroutine, how will the results be stored so that they can be accessed quickly by any code which uses the module? Sorry if I'm explaining myself poorly - feel free to ask for clarification. One more thing - it would be nice to be able to re-parse the config file when someone sends Apache a certain signal. Is this possible? Thanks in advance, Neil -- Neil Conway [EMAIL PROTECTED] Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc Encrypted mail welcomed It should be first patch, not first post. -- Alan Cox PGP signature
Re: [ANNOUNCE] Apache::Session 1.51
On Thu, Jun 01, 2000 at 01:53:10AM -0400, Robin Berjon wrote: Suggestions about making portable database test scripts are welcome. I think that DBD::CSV comes standard with DBI, would testing using that work ? It didn't come standard with my DBI (and it needs SQL::Statement and Text::CSV_XS) -- Neil Conway [EMAIL PROTECTED] Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc Encrypted mail welcomed Nothing can stop the man with the right mental attitude from achieving his goal; nothing on earth can help the man with the wrong mental attitude. -- Thomas Jefferson PGP signature
Re: High-volume mod_perl based ecommerce sites?
On Fri, May 26, 2000 at 09:20:35AM +0800, Gunther Birznieks wrote: Well, yeah, C and Java can suffer the same problems as Perl, but because Java is so constrained as a language, the design of the language has a built in constraint. With Perl you can literally do ANYTHING, and to program Perl in a clean, OO way takes a lot of experience or a good mentor. (I'll apologise in advance as this thread spins rapidly off-topic). I'm probably a novice programmer, at least by the standards of most of the people on this list. I'm 16, and since I haven't taken Computer Science at university yet, I'm a bit lacking in 'formal programming education'. I'd rather not form bad habits - is there any advice anyone can give me on how to write, clean Perl (OO or otherwise)? Are there any good books I can pick up? TIA -- Neil Conway [EMAIL PROTECTED] Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc Encrypted mail welcomed It is dangerous to be right when the government is wrong. -- Voltaire PGP signature
Re: Apache::Session question
On Fri, May 05, 2000 at 05:58:33PM +0200, Francesc Guasch wrote: [Solaris + Apache::Session] After the use Apache::Session you maybe have to type something like this. $Apache::Session::SysVSemaphoreLocker::nsems=16; In my preliminary testing, it appears this is also necessary to get SysVSem working on FreeBSD 3.x (I'm not running 4, but it may also apply there). Can someone confirm this? I had some problems with Apache::Session, tried the above fix, and it seemed to work, but I haven't used Apache::Session since, so I can't be sure. If it IS necessary, it should probably be added to the guide and / or comments in the Apache::Session .pm that controls this (can't remember the filename offhand, but it had a comment referring to Solaris + nsems=16 or 8). TIA -- Neil Conway [EMAIL PROTECTED] Get my GnuPG key from: http://klamath.dyndns.org/mykey.asc Encrypted mail welcomed It is dangerous to be right when the government is wrong. -- Voltaire PGP signature
