On Mon, Oct 6, 2008 at 6:47 AM, Paul Cory <pcory@wcpss.net> wrote:
> All,
>
> I've Googled repeatedly, and RTFMed, and I've reached a point where I have
> to ask for help.
>
> I have a Catalyst Web App that requires users to log in before they can do
> anything (it's a front end for managing mailing list subscriptions).
>
> This runs on Apache 1.3/mod_perl 1/perl 5.8.8/MySQL 5.0 on SLES 10. Apache,
> perl and mod_perl are compiled from source, not the distribution versions.
>
> The problem is that as the day progresses, and the application sees more and
> more use, login behavior becomes inconsistent.
>
> It starts out working flawlessly. Then, after a while, valid logins start to
> occasionally fail. Trying again gets you in - at the start. As time passes,
> the problem gets progressively worse and it eventually gets to the point
> where people quit trying because the success rate for logging in drops to
> 10% or less.
>
> By fail, I mean you go to the log in screen, put in a valid username and
> password combination, and then get seamlessly redirected to the log in
> screen, as if you had just arrived fresh to the app.
>
> Restarting Apache solves the problem, at least for a while. And then things
> begin to degrade again...
>
> I've verified that the problem is not end user error. Once you get it to
> recognize your login, the system work fine.
>
> Other Web Apps I've written, using HTML::Mason and running on this exact
> same server under mod_perl do not exhibit this behavior.
>
> I've checked the Apache error log, and I can't find any related errors.
>
> I'm using the following plug-in for authentication:
>
> Authentication
> Session
> Session::Store::FastMmap
> Session::State::Cookie
>
>
> The problem did not appear in testing, only in production.
>
> Any ideas on where to look, or what to try?
>
> FWIW, here's the login controller code (no promises on it being great -
> programming is something I've learned in self-defense). The controller
> handles log ins for both the regular and admin side of the application.
> First it checks the regular users realm, and, if that fails, then the admin
> users realm (two separate databases) .
>
>
>
> package esubscription::Controller::Login;
>
> use strict;
> use warnings;
> use base 'Catalyst::Controller';
>
>
>
> sub index : Private {
> my ( $self, $c ) = @_;
>
> # Get the username and password from form
> my $login = $c->request->params->{login} || "";
> my $password = $c->request->params->{password} || "";
>
> # If the username and password values were found in form
> if ($login && $password) {
> # Attempt to log the user in
> if ( $c->authenticate({login => $login, password => $password}) )
> {
> # If successful, then let them use the application
> $c->response->redirect($c->uri_for('/'));
> return;
> } else {
>
> if ( $c->authenticate({login => $login, password =>
> $password}, 'admin') ) {
>
> $c->response->redirect($c->uri_for('/admin/'));
> return;
>
> }
>
> else { # Set an error message
>
> $c->stash->{message} = "Bad username or password.";
> $c->stash->{login} = "$login";
> }
> }
> }
>
> # If either of above don't work out, send to the login page
> $c->stash->{template} = 'templates/forms/login_form.mas';
> }
>
>
>
> 1;
>
>
>
> Also, there's this snippet in the root controller that handles checking for
> valid user:
>
> # If a user doesn't exist, force login
>
> if (!$c->user_exists) {
>
> $c->response->redirect($c->uri_for('login'));
> # Return 0 to cancel 'post-auto' processing and prevent use
> of application
> return 0;
> }
>
>
>
> Thanks for the help!
>
>
> Paul Cory
> WCPSS Webmaster
> [email protected: p...@wcpss.net]
>
>
>
Please also send your applications configuration so we can see your
auth store. I do just have to ask though... why such ancient
software? Apache 1 and MP1? Ouch.
Off the top of my head, you are running out of space on your cache dir
(how big is your tmp dir?). If you change your Session::Store or
setup for a larger cache it'd probably alleviate the problem.
-J
Highlight