Re: Apache::Session::MySQL
Is this the correct list for help with Apache::Session::MySQL? This is a good list for it if you are using mod_perl. If you're using CGI, try one of the CGI resources instead, or stick with perlmonks.org. I just replied to your post there a few minutes ago. - Perrin
Re: Apache::Session::MySQL
Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. What do you think? Thanks, Richard. (I'll go see your reply in a min. Thank you!) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 11:49 AM Subject: Re: Apache::Session::MySQL Is this the correct list for help with Apache::Session::MySQL? This is a good list for it if you are using mod_perl. If you're using CGI, try one of the CGI resources instead, or stick with perlmonks.org. I just replied to your post there a few minutes ago. - Perrin
Re: Apache::Session::MySQL
Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? It's not true. The parent process runs as root in order to open port 80, but that's the same for CGI as well. The child processes that actually handle requests runs as whatever user you specify in httpd.conf (typically nobody). I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. If you have clean code (use strict and -w) that will run under mod_perl, you should definitely take advantage of the speed increase. Depending on what you're doing, it can make a really huge difference in performance. I do recommend that you fix your current Apache::Session problem first, before thinking about converting to mod_perl. - Perrin
Re: Apache::Session::MySQL
So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts, without using Mod_Perl, or do I have to use one or the other, only. Thank you, Richard. PS I just replied to the PerlMonks reply you did. Thank you. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 12:08 PM Subject: Re: Apache::Session::MySQL Ah. ok. I don't use Mod_Perl, I hear it is a big security risk, since it runs as root. Is this true? It's not true. The parent process runs as root in order to open port 80, but that's the same for CGI as well. The child processes that actually handle requests runs as whatever user you specify in httpd.conf (typically nobody). I love how much faster it is, it's not that much faster, but enough to make me upgrade all my boxes if it is not a security risk. If you have clean code (use strict and -w) that will run under mod_perl, you should definitely take advantage of the speed increase. Depending on what you're doing, it can make a really huge difference in performance. I do recommend that you fix your current Apache::Session problem first, before thinking about converting to mod_perl. - Perrin
Re: Apache::Session::MySQL
At 01:25 PM 12/28/2002 -0600, Richard wrote: So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts, without using Mod_Perl, or do I have to use one or the other, only. Richard, Yes,you can still run regular cgi, as with MP you have to explicitly tell (via directives in httpd.conf) which files to process using MP handlers. My guess is if you are going to convert cgi scripts to run under MP, you are going to be iinterested in Apache::Registry. There is probably a ton of good info on apache.org and elsewhere about how to do this exactly. GV
Re: Apache::Session::MySQL
So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. Okay, that may be an issue because SuExec does not work with mod_perl. Each apache daemon can only run mod_perl processes as a single user, but that user can be any user you choose. You would never set them to run as root, because that would be a security problem. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts Yes, and you should still be able to run them with SuExec. As George said, there is quite a bit documentation on the perl.apache.org site that may help you. - Perrin
Re: Apache::Session::MySQL
Great, thank you guys! I am trying to first fix my Apache::Session problem before I open a whole new bag of candy :o) Thank you very much for your input, I am grateful! Richard. - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, December 28, 2002 2:32 PM Subject: Re: Apache::Session::MySQL So by user nobody, you mean in the httpd.conf file in the virtualhost tags the user and group? I have it set to user username and group username for each account, since all of our boxes use SuExec. Okay, that may be an issue because SuExec does not work with mod_perl. Each apache daemon can only run mod_perl processes as a single user, but that user can be any user you choose. You would never set them to run as root, because that would be a security problem. So mod_perl is safe Ok. one other question. If I do upgrade to Mod_Perl, can I still run regular Perl scripts Yes, and you should still be able to run them with SuExec. As George said, there is quite a bit documentation on the perl.apache.org site that may help you. - Perrin
Re: Apache::Session::MySQL question regarding lenght of _session_id
On Mon, 18 Dec 2000, Andreas Marienborg wrote: I just can't seem to find any info on how to specify that Apache::Session should create session_id's that are shorter than 32 hex chars? could someone point me in the right direction?? You can use the argument 'IDLength' when using Apache::Session::Generate::MD5 (the default), or you can replace that class with your own class to generate the IDs you desire. See the obscure Apache::Session::Generate::MD5 perldoc. -jwb
Re: Apache::Session::MySQL question regarding lenght of _session_id
at a time earlier than now, Andreas Marienborg wrote:
I just can't seem to find any info on how to specify that Apache::Session
should create session_id's that are shorter than 32 hex chars? could
someone point me in the right direction??
Just write a module to sub class Apache::Session. Apache::Session::MySQL is
remarkably simple. Here it is:
package Apache::Session::MySQL;
use strict;
use vars qw(@ISA $VERSION);
$VERSION = '1.01';
@ISA = qw(Apache::Session);
use Apache::Session;
use Apache::Session::Lock::MySQL;
use Apache::Session::Store::MySQL;
use Apache::Session::Generate::MD5;
use Apache::Session::Serialize::Storable;
sub populate {
my $self = shift;
$self-{object_store} = new Apache::Session::Store::MySQL $self;
$self-{lock_manager} = new Apache::Session::Lock::MySQL $self;
$self-{generate} = \Apache::Session::Generate::MD5::generate;
$self-{validate} = \Apache::Session::Generate::MD5::validate;
$self-{serialize}= \Apache::Session::Serialize::Storable::serialize;
$self-{unserialize} = \Apache::Session::Serialize::Storable::unserialize;
return $self;
}
1;
You can have any subroutine you want generate id's. Just change the two lines
where generate is set to Apache::Session::Generate::MD5::generate and validate
to Apache::Session::Generate::MD5::validate. For example:
package Apache::Session::MyOwnPackage;
use strict;
use vars qw(@ISA $VERSION);
$VERSION = '1.01';
@ISA = qw(Apache::Session);
use Apache::Session;
use Apache::Session::Lock::MySQL;
use Apache::Session::Store::MySQL;
use Apache::Session::Serialize::Storable;
sub populate {
my $self = shift;
$self-{object_store} = new Apache::Session::Store::MySQL $self;
$self-{lock_manager} = new Apache::Session::Lock::MySQL $self;
$self-{generate} = \generate;
$self-{validate} = \validate;
$self-{serialize}= \Apache::Session::Serialize::Storable::serialize;
$self-{unserialize} = \Apache::Session::Serialize::Storable::unserialize;
return $self;
}
sub generate
{
# some code to generate ids
}
sub validate
{
# some code to validate ids
}
1;
Of course, you'll actually need to write some code to generate and validate
ids. :)
HTH,
Aaron
thanks in advance
Andreas
--
Andreas Marienborg+47 92 28 63 82
[EMAIL PROTECTED] www.palle.net
--
---
Caution! The beverage you are about to enjoy may be hot.
Re: Apache::Session::MySQL question regarding lenght of _session_id
On Mon, 18 Dec 2000, Aaron E. Ross wrote: at a time earlier than now, Andreas Marienborg wrote: I just can't seem to find any info on how to specify that Apache::Session should create session_id's that are shorter than 32 hex chars? could someone point me in the right direction?? Just write a module to sub class Apache::Session. Apache::Session::MySQL is remarkably simple. Here it is: Thanks for pointing this out..however, I found a better way I thought I'd share with the list: The Apache::Session::Generate::MD5 module actually checks if there is an arg called 'IDLength' when it generates the ID...so I just had to add an IDLength = 8 to my initial Session tie, and everything worked nicely from there on :) Thanks for pointing me in the right direction! -- Andreas Marienborg +47 92 28 63 82 [EMAIL PROTECTED] www.palle.net
Re: Apache::Session::MySQL problem
Thu, 20 Jul 2000 14:29:40 -0700 (PDT) "Jeffrey W. Baker" [EMAIL PROTECTED] wrote: The problem is, if an acquired Session ID (from Cookie) is not stored in the session database, Apache goes like panic: POPSTACK Callback called exit. I know Apache::Session will die "Object does not exist in the data store" when it can't restore a session from database. So my script catch that exception with eval block. But panic will happen. why ? Bug in Perl. Upgrade. my perl version is 5.005_03 with FreeBSD 4.0. shoud I update this to perl 5.6.0 ?? +-+-+-+-+-+-+-+-+-+- Tatsuhiko Miyagawa [EMAIL PROTECTED]
