modperl caching userids

js1 has asked for the wisdom of the Perl Monks concerning the following question:

Monks,

I have this problem with a webpage perl script which does password changes. The user is presented a form with one field for their old password and two fields to confirm their new password.

It works perfectly except for the delay in loading the modules, so I'm trying to run it on modperl 2, which has greatly increased the speed now. However, now it seems to be caching the usernames and passwords, which is leading to all kinds of problems. I'm not sure what to do so wondered if you could help me out please?

Yours humbly.

JS.

Comment on modperl caching userids

Replies are listed 'Best First'.
Re: modperl caching userids by Joost (Canon) on May 14, 2004 at 13:18 UTC
Look at the relevant documentation for this kind of problem. if you don't get enlightened, please post some code that shows the problem. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re: modperl caching userids by perrin (Chancellor) on May 14, 2004 at 13:22 UTC
You are either putting the value in a global or a closure. Post a little code and we can probably spot the problem.	[reply]
Re: modperl caching userids by matsmats (Monk) on May 14, 2004 at 13:32 UTC
This is a shot in the dark, but I've been spending plenty of time trying to analyze an identical problem with access control when changing from modperl 1 to modperl 2 If a user is passed on with a Location: header with a reference to a local file, Apache 2, in contrary to the 1-generation, locates the file and passes it to the user without making it a new request. Meaning that your ModPerl access control handlers are never run -and depending on your code, it might seem like the username/password is cached! If this could be the case, I suggest doing all Location-headers with absoulte URLs, domain and all. Hope this helps. Another suggestion would be to log everything you're doing in the handlers and see if they actually run at all requests. Mats	[reply]