RE: Authentication design
Perrin Harkins wrote (in a discussion with Michael L. Artz): Well, I figured that the AuthenHandler already parsed the authentication cookie and declared it valid, so I didn't really see a point the in doing it at the beginning of every script. $r-user just seemed more intuitive to me. Well, I'm not sure what's involved in determining $r-user aside from reading the cookie. It may not make any difference. Here's a typical pattern for this: [...] The session stuff could be done in a separate phase before the content handler, or it could be done on demand when your script calls some utility method that knows how to get the current session. Same with the user. Isn't this more a matter of 'niceness'? Putting the session/user stuff in AuthenHandler and then setting the $r-user makes it clear where the authentication takes place. All other handlers just check if $r-user is set and need not to bother with sessions and stuff? Or is there something against this and would you be a supporter of having it all in the same handler? --Frank
Re: undefined symbol: PL_stack_base
On Wed, 2003-06-11 at 04:34, Stas Bekman wrote: Are you sure that you compiled with the same perl that gets loaded? ldd /etc/apache/extramodules/libperl.so will show you which libperl.so (this time perl's) it's linked against. Then you check that libperl.so to see if it has the symbol defined: nm /path/to/CORE/libperl.so | grep PL_stack_base My guess is that you may have more than one perls on your machine and mod_perl picks the wrong library at the startup. I just fixed the problem, it's because I had perl compiled with threads enabled. I think there's a bug in Gentoo WRT this. Supposedly this bug happens when perl and libperl are compiled with and without threads resp.
static linking vs DSO linking
At a recent client, I had the mandate to develop a front/back server setup, with the front being a thin mod_proxy setup and the back being a fat mod_perl setup. One of the things I noticed while compiling and deploying Apache on Solaris via the pmap command is that the static linking and selective loading (via LoadModule) didn't really save me that much stuff... only the AddModule selected whether the module had been activated, and therefore allocated its private memory. Has anyone else seen this? Am I crazy for suggesting that DSO doesn't really gain you much, and a simple selective AddModule is enough? Also, has anyone gotten experience with AddModule mod_perl but keeping the front-end's mod_perl tasks to a minimum, and therefore the memory footprint very small? I want the backend's mod_perl usage to be fat: that's the whole point of the divergence. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: static linking vs DSO linking
Hi Randal, On 11 Jun 2003, Randal L. Schwartz wrote: Am I crazy for suggesting that DSO doesn't really gain you much...? 'Sfunny you should say that... Also, has anyone gotten experience with AddModule mod_perl but keeping the front-end's mod_perl tasks to a minimum, and therefore the memory footprint very small? Never had to worry about it a great deal, I usually just throw RAM or boxes at it. Maybe you could have a look at Squid or something? 73, Ged. -- On Tue, 10 Jun 2003, Ged Haywood wrote: On Tue, 10 Jun 2003, Forrest Aldrich wrote: I wonder if this will affect anything else, especially other things that require DSO support. ? Have you got the Eagle Book? You need --enable-module=so in your configure arguments to put mod_so into Apache, mod_so allows Apache to load shared objects. What does --enable-shared=max imply to Apache... make as much as possible as shared objects, the idea being to make the resulting binary smaller. It won't save any memory if you run it with tons of modules loaded, so it's probably more trouble than it's worth. Which is my opinion of DSO generally. I always build static if I can.
Re: Authentication design
Perrin Harkins wrote: Well, I'm not sure what's involved in determining $r-user aside from reading the cookie. It may not make any difference. Here's a typical pattern for this: - Fetch the session key from the validated cookie. - Load the session using that key. - Grab the user ID from the session. - Load the user's data based on that ID. The session stuff could be done in a separate phase before the content handler, or it could be done on demand when your script calls some utility method that knows how to get the current session. Same with the user. Not sure that I quite understand ... what do you mean by load the session/user data if it is being done in a handler before content phase? What would you use to store the retrieved data ... pnotes? Also, I am not quite sure of the distinction between session data and user data. Wouldn't session data be intrinsically tied to a user? My session table currently looks like [user_id, session_key, session_data, login_time, last_access_time]. I guess I am currently using the session table to be more of an authentication table, i.e. if you give me a good user_id/session_key ticket that matches what is in the database. I guess my pattern is: within PerlAuthenHandler -Check to see if there are passed user/password params. If so, validate params against user/pass in database. If the params are valid, create a new session key, store the session key in the database, and set a cookie with the user_id and session_key. -Otherwise, if there is a cookie, validate the cookie's user_id/session against the database one stored in the database. -If either the params or cookie passed muster, set $r-user and return Apache::OK. If the user passed incorrect parameters, redirect to a custom_error form which is the login page. Otherwise, return Apache::OK and do not set $r-user. within registry scripts: -If $r-user is set, turn on custom pages and load user preferences. -Mike
Re: Authentication design
There are at least 2 places where the idea can be improved to be even better: 1) for browsers that do not support cookie, embed the ticket/credential in the URL so the system works for all browsers 2) the part for ticket verification can be written in C so in case of dual-server setup (light plus proxy), which is kind of popular now, one can set it up in the light server to protect static content. Peter - Original Message - From: Michael L. Artz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 6:47 PM Subject: Re: Authentication design Well, sorta. I am actually using a custom module very similar to the one found in the cookbook (and AuthCookie, I think), i.e. create a PerlAuthenHandler that sets the custom error message to the login page and redirects you to it if you pass it an incorrect user/password request. If it the user/pass checks out, I set a session cookie (md5 sum of stuff), store the session_key in the database (Postgres), and set $r-user. If no user/password or cookie is presented, I just return OK for most of the site. A couple of scripts are login-only, and those are protected by an authz handler that makes sure $r-user is set. Everything is handled with my custom login forms, none of the crappy pop-ups for basic or digest authentication. So I guess that I am usurping the normal HTTP-authentication phase for my own nefarious purposes. I thought that this was a good way to go since I could protect my entire application with a single module and a couple lines in the config file, as opposed to bundling that authentication code into the beginning of *every* registry script that I write. And, from lurking on the board for a long time, I got the feeling that this is how everyone is doing it is that a correct assumption? -Mike
Re: Simple DAV Server?
Trevor Phillips wrote: On Wednesday 11 June 2003 05:13, you wrote: Trevor Phillips wrote: I'm quite suprised at the limited amount of custom DAV server uses. I mean, here's a protocol for editing content over HTTP, which to me screams as an ideal solution for, say, editing full HTML content within a DB/CMS. I think the problem with webDAV, as a protocol through which to manipulate web pages, lies in the fact that it is difficult to manipulate dynamic content without sending the rendered content to the client, instead of the true source. (Phew!! That was long winded... :P ) The only way that I have found to do it, is to either break the web server, (ie publish to a web server that doesn't have the dynamic language engine installed), or... (I don't know of another solution that works... :( ) I'm aware of the issue, but don't see it as a show-stopper. You could use an alternate URL to direct DAV handling to a different handler. ie; To view: /path/to/content/ To edit: /dav/path/to/content/ ... where the module associated with /dav/ knows how to retrieve the raw content (be it files, or a map to DB-stored content) of the normal path. When viewing the content, you could provide links to the edit version of the URL. This is probably not the appropriate venue for a discussion on webDAV, but I feel that this type of work-around, which I use, is not appropriate. I think that there will need to be an addition to HTTP, which will define the difference between a GET for viewing content, and a GET for publishing... Since webDAV is a standard, it should be possible to argue the need for such a device. If we can get that device introduced into HTTP, then after a time, client applications will be altered to work thus, and voila!! Until then, I find this approach to be less than satisfactory speeves cws
Re: Installing Apache::AuthCookie
On Tue, 10 Jun 2003, Jay Strauss wrote: I'm running into a problem during the make test while installing the current version of Apache::AuthCookie. I'm not sure where to go. I looked at tests 10 and 15: Hrm. You are supposed to get ok for all of the tests. If I had to guess from this I would say that there is something in your httpd.conf (that Apache::test is pulling the config from) that is screwing up the tests. Can you send me your t/httpd.conf? (privately, no need to send it to the list). Regards Michael -- Hal 9000 - Put down those Windows disks Dave Dave? DAVE!!
security with mod_perl
I have a local hosting provider who has mod_perl installed on the server, but will not enable it for security reasons. After doing some digging on the mod_perl site and thinking about how many ways a renegade mod_perl program could bring down a site (large modules using a lot of memory means larger httpd process, consumes memory, hurts performance, etc.). I couldn't find any documentation on how a host *could* provide mod_perl and do it in a way that would be safe for his server and usable for a client. Maybe some way to restrict memory space or something? One problem I see is that Stat::INC would need to be enabled for everything (at least in the clients sandbox). I guess performance-wise, this would still be way better than straight CGI. Thanks for any help. If there is an M out there for this, please tell me to RTF! I looked into some of the sites listed on the mod_perl providers page on perl.apache.org. However, most of these sites are $99+ per month. My lowly non-profit clients can't afford this much $. I'm debating getting a bunch of non-profits together and do a dedicated server, but I'd rather not do that unless I have to. Thanks, Mike Zelina
Re: security with mod_perl
We use BSD::Resource for our mod_perl clients. Keeps them from eating the machine alive. On another shared machine each client gets their own interpreter with some pretty tight limits on child spawning, open children etc. on top of the Resource limits Shared hosting mod_perl is a real drag to do though unless everyone is pretty low traffic. I'm probably not doing it right, its a 'grown' solution for a few clients, not a huge solution engineering for mass hosting. John- On Wed, 11 Jun 2003 09:58:54 -0700 Mike Zelina [EMAIL PROTECTED] wrote: I have a local hosting provider who has mod_perl installed on the server, but will not enable it for security reasons. After doing some digging on the mod_perl site and thinking about how many ways a renegade mod_perl program could bring down a site (large modules using a lot of memory means larger httpd process, consumes memory, hurts performance, etc.). I couldn't find any documentation on how a host *could* provide mod_perl and do it in a way that would be safe for his server and usable for a client. Maybe some way to restrict memory space or something? One problem I see is that Stat::INC would need to be enabled for everything (at least in the clients sandbox). I guess performance-wise, this would still be way better than straight CGI. Thanks for any help. If there is an M out there for this, please tell me to RTF! I looked into some of the sites listed on the mod_perl providers page on perl.apache.org. However, most of these sites are $99+ per month. My lowly non-profit clients can't afford this much $. I'm debating getting a bunch of non-profits together and do a dedicated server, but I'd rather not do that unless I have to. Thanks, Mike Zelina
RE: security with mod_perl
Not quite a manual, but read some of these discussions on PerlMonks: http://www.perlmonks.org/index.pl?node=mod+perl+isp+hostgo_button=Search mod_perl shared hosting ISPs supporting mod_perl mod_perl: the bane of share webhosting Hope this gives you some answers (not a lot of hope, though) -Sidharth. -Original Message- From: Mike Zelina [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2003 12:59 PM To: [EMAIL PROTECTED] Subject: security with mod_perl I have a local hosting provider who has mod_perl installed on the server, but will not enable it for security reasons. After doing some digging on the mod_perl site and thinking about how many ways a renegade mod_perl program could bring down a site (large modules using a lot of memory means larger httpd process, consumes memory, hurts performance, etc.). I couldn't find any documentation on how a host *could* provide mod_perl and do it in a way that would be safe for his server and usable for a client. Maybe some way to restrict memory space or something? One problem I see is that Stat::INC would need to be enabled for everything (at least in the clients sandbox). I guess performance-wise, this would still be way better than straight CGI. Thanks for any help. If there is an M out there for this, please tell me to RTF! I looked into some of the sites listed on the mod_perl providers page on perl.apache.org. However, most of these sites are $99+ per month. My lowly non-profit clients can't afford this much $. I'm debating getting a bunch of non-profits together and do a dedicated server, but I'd rather not do that unless I have to. Thanks, Mike Zelina
RE: security with mod_perl
On Wed, 2003-06-11 at 18:09, Sidharth Malhotra wrote: Not quite a manual, but read some of these discussions on PerlMonks: http://www.perlmonks.org/index.pl?node=mod+perl+isp+hostgo_button=Search mod_perl shared hosting ISPs supporting mod_perl mod_perl: the bane of share webhosting Hope this gives you some answers (not a lot of hope, though) You can get nice virtual servers from only 15 GBP / month ( probably about the same in merkan money for similar hosting in the US ). Quite why anybody would want shared hosting when you can have a virtual server (usually with ensim and stuff for newbies) for such a low ammount of money. http://www.bytemark-hosting.co.uk do some good deals and discounts for free software author and seem nice people. -- Aaron Trevena, BSc (Hons) --- Software Engineer Tusker Direct :: www.tuskerdirect.com
[mp2] make test fails nearly all tests...
Title: [mp2] make test fails nearly all tests... I've searched the list archives for relevant postings, and I found a couple of messages with similar problems, but no answers. I think I've included all relevant details. Please let me know if there is something else I should add. I'm working with a fresh install of RedHat 7.3. Perl is v5.8.0 compiled from source. I built it with support for ithreads. Apache is 2.0.46. To install Apache I did: tar -xvzf httpd-2.0.46.tar.gz cd httpd-2.0.46 ./configure --prefix=/usr/local/apache2 make make install I then tested httpd and it is serving pages correctly. mod_perl is 1.99_09. I did: tar -xvzf mod_perl-2.0-current.tar.gz cd mod_perl-1.99_09 perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 make make test Everything up through make seems to have gone fine. I was logged in as root for everything. Below I've pasted the contents of t/REPORT and error_log. -8-- Start Bug Report 8-- 1. Problem Description: See above 2. Used Components and their Configuration: *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_AP_PREFIX = /usr/local/apache2 MP_COMPAT_1X = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 MP_USE_STATIC = 1 *** /usr/local/apache2/bin/httpd -V Server version: Apache/2.0.46 Server built: Jun 10 2003 11:22:58 Server's Module Magic Number: 20020903:3 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/usr/local/apache2 -D SUEXEC_BIN=/usr/local/apache2/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** /usr/local/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.18-3smp, archname=i686-linux-thread-multi uname='linux uss-nimitz.fefcful.org 2.4.18-3smp #1 smp thu apr 18 07:27:31 edt 2002 i686 unknown ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.3 2.96-110)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldl -lm -lpthread -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Jun 10 2003 10:07:11 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: /usr/local/lib/perl5/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl . 3. This is the core dump trace: (if you get a core dump): [CORE TRACE COMES HERE] This report was generated by t/REPORT on Wed Jun 11 15:52:57 2003 GMT. -8-- End Bug Report --8-- ***Error log END in modperl_extra.pl, pid=32338 [Tue Jun 10 12:16:19 2003] [notice] Apache/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.8.0 configured -- resuming normal operations [Tue Jun 10 12:16:19 2003] [info] Server built: Jun 10 2003 11:22:58 [Tue Jun 10 12:16:19 2003] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem) [Tue Jun 10 12:16:19 2003] [error] failed to resolve handler `TestHooks::trans' [Tue Jun 10 12:16:19 2003] [error] [client 127.0.0.1] Can't locate TestHooks/trans.pm in @INC (@INC contains:
Re: security with mod_perl
On Wed, 2003-06-11 at 12:58, Mike Zelina wrote: I couldn't find any documentation on how a host *could* provide mod_perl and do it in a way that would be safe for his server and usable for a client. I was just talking about this with my co-workers. Here's one way: Set up a front-end apache with mod_proxy. Have it proxy all requests for /~user (or whatever) to an unprivileged port assigned to that user (or a name-based virtual host). Give each user their own mod_perl on that port/host that they can do what they want with, since it runs as an unprivileged user (themselves). However, it's quite possible that this is more trouble and less value than the virtual server setups people are selling these days. - Perrin
RE: Authentication design
On Wed, 2003-06-11 at 03:32, Frank Maas wrote: The session stuff could be done in a separate phase before the content handler, or it could be done on demand when your script calls some utility method that knows how to get the current session. Same with the user. Isn't this more a matter of 'niceness'? I'm not sure what you mean. Putting the session/user stuff in AuthenHandler and then setting the $r-user makes it clear where the authentication takes place. All other handlers just check if $r-user is set and need not to bother with sessions and stuff? Are you asking why anyone would get this on demand instead of always doing it in an auth handler? One reason might be that fetching the session and user is expensive, and you don't know if you'll need it or not just based on the URL. Or is there something against this and would you be a supporter of having it all in the same handler? If using a separate handler makes sense for your app and you like it that way, then do it. - Perrin
RE: PerlOptions Clone/Parent in mp2
The code to implement blocks (e.g. TIPool.../TIPool) in config files is pretty gnarly, too. I know it's already there for Perl, it's one of the places I looked when I was considering doing one of my own and wanted to see an example. The Apache framework is pretty strong for putting in new directives, but not so much for adding new blocks. Actually you can't quite do that in a 3rd party module. Currently the pools are internal to mod_perl. Making this customizable will require adding hooks to the internal tipool mechanism. When I wrote the above pseudo-config I was suggesting an internal support for these. I was actually not figuring to do it myself. ;) I was commenting on the code required to implement things like Perl or TIPool. I've since queried the httpd-dev list and the 'official' example is in the source for mod_proxy (with a caveat that a three-pass config file parser may necessitate further changes at some point). It appears to be a lot simpler than the parsing that mod_perl is doing. I was wondering...is there a specific reason mod_perl implements Perl the way it does or is it just code inertia? mma
Re: Authentication design
On Wed, 2003-06-11 at 08:32, Michael L. Artz wrote: Not sure that I quite understand ... what do you mean by load the session/user data if it is being done in a handler before content phase? What would you use to store the retrieved data ... pnotes? That's what I've done in the past, although the users of the API didn't know that. We just made a get_session() method that returns the session. The first time it runs, it does the work. After that, it caches the session in pnotes() and gets it there for the remainder of the request. Also, I am not quite sure of the distinction between session data and user data. Wouldn't session data be intrinsically tied to a user? Don't you ever have to keep track of anything before you know who the user is? When I say user data I mean permanent data; things like the user's contact info and security allowances, not what's in page 2 of the form they are filling out. My session table currently looks like [user_id, session_key, session_data, login_time, last_access_time]. I guess I am currently using the session table to be more of an authentication table, i.e. if you give me a good user_id/session_key ticket that matches what is in the database. That's fine if it fits your requirements. I guess my pattern is: within PerlAuthenHandler -Check to see if there are passed user/password params. If so, validate params against user/pass in database. If the params are valid, create a new session key, store the session key in the database, and set a cookie with the user_id and session_key. Isn't the session key unique? Why put both in the cookie? -Otherwise, if there is a cookie, validate the cookie's user_id/session against the database one stored in the database. -If either the params or cookie passed muster, set $r-user and return Apache::OK. If the user passed incorrect parameters, redirect to a custom_error form which is the login page. Otherwise, return Apache::OK and do not set $r-user. within registry scripts: -If $r-user is set, turn on custom pages and load user preferences. That all sounds fine to me. - Perrin
Re: security with mod_perl
Perrin Harkins wrote: On Wed, 2003-06-11 at 12:58, Mike Zelina wrote: I couldn't find any documentation on how a host *could* provide mod_perl and do it in a way that would be safe for his server and usable for a client. I was just talking about this with my co-workers. Here's one way: Set up a front-end apache with mod_proxy. Have it proxy all requests for /~user (or whatever) to an unprivileged port assigned to that user (or a name-based virtual host). Give each user their own mod_perl on that port/host that they can do what they want with, since it runs as an unprivileged user (themselves). You still have a problem to limit available resources. On some platforms BSD::Resource/Apache::Resource can solve this as John has suggested. However, it's quite possible that this is more trouble and less value than the virtual server setups people are selling these days. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: security with mod_perl
Aaron Trevena wrote: [...] http://www.bytemark-hosting.co.uk do some good deals and discounts for free software author and seem nice people. Please submit ISPs that support mod_perl and/or virtual servers. so we can add them to: http://perl.apache.org/help/isps.html I've added the one mentioned above by Aaron. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] make test fails nearly all tests...
Tim Howell wrote: I've searched the list archives for relevant postings, and I found a couple of messages with similar problems, but no answers. I think I've included all relevant details. Please let me know if there is something else I should add. I'm working with a fresh install of RedHat 7.3. Perl is v5.8.0 compiled from source. I built it with support for ithreads. Apache is 2.0.46. To install Apache I did: [...] Thanks for the detailed report Tim. [Tue Jun 10 12:16:19 2003] [error] failed to resolve handler `TestHooks::trans' [Tue Jun 10 12:16:19 2003] [error] [client 127.0.0.1] Can't locate TestHooks/trans.pm in @INC (@INC contains: Apache-Test/lib /root/mod_perl-1.99_09/Apache-Test/lib /root/mod_perl-1.99_09/lib /root/mod_perl-1.99_09/blib/lib /root/mod_perl-1.99_09/blib/arch /root/mod_perl-1.99_09/t/response /root/mod_perl-1.99_09/t/protocol /root/mod_perl-1.99_09/t/preconnection /root/mod_perl-1.99_09/t/hooks /root/mod_perl-1.99_09/t/filter /root/mod_perl-1.99_09/t /root/mod_perl-1.99_09/t/htdocs/testdirective/perlmodule-vh /root/mod_perl-1.99_09/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl /root/mod_perl-1.99_09/t/ /root/mod_perl-1.99_09/t/lib/perl) at (eval 51) line 3. Looks like you encounter permission problems. Since you have /root/mod_perl-1.99_09/t/hooks in the path. I'm pretty sure that if you build/test as a normal user and only su to install, everything will work just fine. We try to provide a workaround for testing with root and what we do is chown the files to the uid/gid the server is configured to run with. This is because the server can't be run as root for security reasons. Can you do: grep User t/conf/httpd.conf it tries to pick the 'httpd' or 'nobody' user to run the tests with. If you don't have such user on your machine this may explain the problem you are having. Also, I'd like to see the output of 'make test', since it tells me when it chowns the files and to which uid/gid. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Authentication design
Hmm, I see now. I don't really care about users who aren't logged in, so I don't know that there is a need to store session data for them. I guess my pattern is: within PerlAuthenHandler -Check to see if there are passed user/password params. If so, validate params against user/pass in database. If the params are valid, create a new session key, store the session key in the database, and set a cookie with the user_id and session_key. Isn't the session key unique? Why put both in the cookie? Because my session table is indexed off the user_id. I know that it probably won't matter until I have something like 100+ nearly-simultaneous users, but I thought that it would be nice to plan ahead, just in case. I guess what I am hearing is the good-ole Perl adage: tmtowtdi. I think that what I have both works and seems to fit my needs just fine, so I will stick with it, just wanted to make sure that it wasn't glaringly horrible for some reason. Thanks to all who chimed in. -Mike
Re: Installing Apache::AuthCookie
I installed it anyway. It seems to be working. I can still send you the httpd.conf if you'd still like jay - Original Message - From: Michael Schout [EMAIL PROTECTED] To: Jay Strauss [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, June 11, 2003 11:26 AM Subject: Re: Installing Apache::AuthCookie On Tue, 10 Jun 2003, Jay Strauss wrote: I'm running into a problem during the make test while installing the current version of Apache::AuthCookie. I'm not sure where to go. I looked at tests 10 and 15: Hrm. You are supposed to get ok for all of the tests. If I had to guess from this I would say that there is something in your httpd.conf (that Apache::test is pulling the config from) that is screwing up the tests. Can you send me your t/httpd.conf? (privately, no need to send it to the list). Regards Michael -- Hal 9000 - Put down those Windows disks Dave Dave? DAVE!!
Re: [mp2] Apache::compat breaking 2.0 API solutions?
Stas Bekman wrote:
Last night I have done the mod_perl 1.0 to 2.0 porting presentation at
the Melbourne mongers meeting, and I have raised the issue with
Apache::compat, asking for input from my audience. Here is the problem
that we have:
Apache::compat provides mod_perl 1.0 backward compatibility
implementation. And everything works just fine as long as the API has a
different name. However there is a problem if a certain method has the
same name but a totally different functionality. Here is an example:
As explained here:
http://perl.apache.org/docs/2.0/user/porting/compat.html#C__connection_E_gt_remote_addr_
in mod_perl 1.0 you'd say:
use Socket 'sockaddr_in';
my ($port, $ip) = sockaddr_in($r-connection-remote_addr);
i.e. $r-connection-remote_addr was returned a packed socket information.
However in mod_perl 2.0 lingo (read: Apache 2.0 lingo),
$r-connection-remote_addr returns an APR::SockAddr object (read: an
opaque object, to which you need to use methods to access its values).
So to accomplish the above you need to do:
require APR::SockAddr;
my $sock_addr = $c-remote_addr;
my ($port, $ip) = ($sock_addr-port_get, $sock_addr-ip_get);
this is a 1:1 mapping to the Apache 2.0 C API.
So if we provide a back-compat implementation in Apache::compat and it
gets loaded the real 2.0 API can no longer be used.
What I suggested is that we need some sort of scoped pragmata, so we can
say:
{
use mod_perl::compat;
my ($port, $ip) = sockaddr_in($r-connection-remote_addr);
}
my $sock_addr = $c-remote_addr;
my ($port, $ip) = ($sock_addr-port_get, $sock_addr-ip_get);
so I can use both APIs and enable the back-compatibility functionality
only in the needed scope. Of course this doesn't make the porting as
simple as enabling Apache::compat, but it solves the API breaking
problem. If it was only possible to make the scoping work.
And Scott Penrose, of the melbourne pm's fame sent me these suggestions
(posted here with Scott's permission):
Original Message
Subject: Two solutions to Apache::compat
Date: Thu, 12 Jun 2003 12:47:28 +1000
From: Scott Penrose [EMAIL PROTECTED]
To: Stas Bekman [EMAIL PROTECTED]
I have two solutions for your problem you presented yesterday.
Both have side effects but I can work them at least in part (I don't
know all the gotchas with ModPerl though).
1) Filter::Simple
use Apache::compat::uber;
# or what ever it actually is...
print STDERR sockdaddr_in($r-localaddr);
no Apache::compat::uber;
print STDERR $r-localaddr-ipnumber;
will get converted to this
print STDERR sockaddr_in($r-localaddr_compat);
print STDERR $r-localaddr-ipnumber;
This has the side effect of having to do a Filter stage which is slower
start up (but not much) and you have to get the regular expression
right, but that won't be hard.
2) Operator Overload
use Apache::compat;
# or what ever it actually is...
print STDERR sockdaddr_in($r-localaddr);
print STDERR $r-localaddr-ipnumber;
$r-localaddr returns an operator overloaded object which can then
check if we are returning a scalar (return the packed local address) or
are we returning a blessed reference (return the normal blessed
reference). I use this approach for code like this.
print $md-DC-Title . \n;
print $md-DC-Title-Short . \n;
Scooter
- --
Scott Penrose
Open source developer
http://linux.dd.com.au/
[EMAIL PROTECTED]
NetBSD 1.5.3 perl 5.6.1 mod_perl 1.99_09 Install sucessfully.
The message is for notice about the installation of mod_perl 1.99_09 and Apache 2.0.46 with Perl 5.6.1 under NetBSD 1.5.3. Such installation was easy but slow in my old Pentium MMX 200 with 32 MB RAM. [/home/admin $ ]sudo /usr/local/apache2/bin/apachectl status Not Found The requested URL /server-status was not found on this server. _ Apache/2.0.46 (Unix) mod_perl/1.99_09 Perl/v5.6.1 Server at localhost Port 80 [/home/admin $ ]
Re: [mp2] Apache::compat breaking 2.0 API solutions?
[...] From: Scott Penrose [EMAIL PROTECTED] To: Stas Bekman [EMAIL PROTECTED] I have two solutions for your problem you presented yesterday. Both have side effects but I can work them at least in part (I don't know all the gotchas with ModPerl though). 1) Filter::Simple use Apache::compat::uber; # or what ever it actually is... print STDERR sockdaddr_in($r-localaddr); no Apache::compat::uber; print STDERR $r-localaddr-ipnumber; will get converted to this print STDERR sockaddr_in($r-localaddr_compat); print STDERR $r-localaddr-ipnumber; This has the side effect of having to do a Filter stage which is slower start up (but not much) and you have to get the regular expression right, but that won't be hard. Sounds good to me. Anybody has an experience of using Filter::Simple with mod_perl? What perl versions Filter::Simple is working with? Assuming that someone will need to use this trickery to get the same code working with mod_perl 1.0 and mod_perl 2.0? 2) Operator Overload use Apache::compat; # or what ever it actually is... print STDERR sockdaddr_in($r-localaddr); print STDERR $r-localaddr-ipnumber; $r-localaddr returns an operator overloaded object which can then check if we are returning a scalar (return the packed local address) or are we returning a blessed reference (return the normal blessed reference). I use this approach for code like this. print $md-DC-Title . \n; print $md-DC-Title-Short . \n; How do you cope with a situation like this: my $title = $md-DC-Title; which can then be: print $title; or: print $title-Short; of course you can overload the operator so it'll magically work because print calls . Is that what you meants by your example? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
mp2: really dumb q re getting values sent to a form
My appologies, I've tried to grok this from the doco, but must have missed it somewhere while trying to parse apache::request somehow? I've got a script, I want to grab submitted values to it of the form : http://foo.bar/perl/script.pl?a=4 And I want to be able to work out what a is within script.pl, ie, within the script I want to set a to 4, or whatever it gets called as. I know this is trivially easy to do with CGI.pm, but how do I do it without CGI.pm? (caveats concerning taint etc appreciated) Carl
Re: [mp2] Apache::compat breaking 2.0 API solutions?
Scott Penrose wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
sounds good to me. Anybody has an experience of using Filter::Simple
with mod_perl?
A simple version looks like this...
package Apache::compat::uber;
use strict;
use Filter::Simple;
use constant ahh = 0;
FILTER {
print STDERR PRE = $_\n if ahh;
s/localaddr/localaddr_compat/g;
print STDERR POST = $_\n if ahh;
};
1;
And thats it... of course you have to write localaddr_compat in the
Apache::compat module.
(mind you, this is untested :-)
What perl versions Filter::Simple is working with? Assuming that
someone will need to use this trickery to get the same code working
with mod_perl 1.0 and mod_perl 2.0?
Filter::Simple works with 5.6+
Thanks Scott, I'll give it a try.
2) Operator Overload
use Apache::compat;
# or what ever it actually is...
print STDERR sockdaddr_in($r-localaddr);
print STDERR $r-localaddr-ipnumber;
$r-localaddr returns an operator overloaded object which can then
check if we are returning a scalar (return the packed local address) or
are we returning a blessed reference (return the normal blessed
reference). I use this approach for code like this.
print $md-DC-Title . \n;
print $md-DC-Title-Short . \n;
How do you cope with a situation like this:
my $title = $md-DC-Title;
which can then be:
print $title;
or:
print $title-Short;
Both work, because in the first case it will be stringified to the
actual title.
(although, sometimes you have to do print . $title;
In the second it will request from the overload method a blessed reference.
of course you can overload the operator so it'll magically work
because print calls . Is that what you meants by your example?
Yes :-) note to self, read bottom before replying above :-)
;)
It aint perfect. The Filter::Simple would probably be more reliable.
It also won't work in the case of APR::URI::unparse which has a different
problem. It'd be nice to have a generic solution.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
