Jonathan Vanasco wrote:
On Oct 3, 2006, at 1:30 AM, David Emery wrote:
Just a shot in the dark, but could it be a problem with your log-in
process
rather than a caching issue? Like maybe the unique value you're basing
the
user's identity on isn't quite as unique as you think?
I'm going to agree with this being AT LEAST the first place to shift
your focus.
Since the issue you have happens so rarely, you don't really know if the
pragma thing has anything to do within it. All of your tests seem to be
within a margin of error.
How exactly are you logging people in ? How are they identified in a
database? How are they identified to the server after they have been
verified through the db? How are cookies being made / handled / sent to
the server ?
Is it possible that you're experiencing improbable but fully possible
collisions in md5 values?
Also, have you been debugging the actual login logic, and then going
through logs to match up what was happening with an error? there could
be some odd issue where people have similar passwords or logins, and the
verification code sucks.
I have thoroughly checked the login logic, and the evidence really does
seems to point to some kind of caching. Like you said, I can't be
completely sure, so I'll describe how the login process works. Users enter
their username and password into a login form which POSTs to a Registry
script. The script gets the parameters via CGI.pm, runs a few regexes to
check for strange characters, and calls a sub named validate_user(), passing
the username and password to it. The sub executes a database query to fetch
a row matching the username, if any, and makes sure the fetched user/pass
match the form user/pass. A hash is returned with all of the user's
account info (if they don't match, the sub returns 0, and the script prints
a typical wrong password message).
I've done many diagnosics on this. For example, I added some code to the
script that, right before sending the header, decrypts the cookie to make
sure that it matches the form params.
One time, two different users reported this problem at roughly the same
time. But what is interesting is that not only did they both enter *a*
wrong account, they both entered the *same* wrong account! And we have
almost 100,000 users in our database! The script keeps a log of the
numerical user ID, IP address, and timestamp of each successful user to
login, and whenever someone reports entering the wrong account, nothing
unusual or having a pattern ever shows up there either. If something was
wrong with the login logic, I would expect to see an entry with the user ID
of one user and the IP of the other user. That's never happened.
I'm using two way encryption (using the Crypt::CBC module) instead of MD5,
so collisions aren't an issue. The username and password are both encrypted
individually. The set-cookie header is generated like this:
my $cookieobject = $cgi->cookie(-name => 'logininfo', -value =>
[($encrypted_user, $encrypted_pass)]);
print
$cgi->redirect(-cookie=>$cookieobject, -location=>'/youarenowloggedin');
On visits to other pages, the user and pass are retrieved from the cookie,
decrypted, and revalidated using the same validate_user() sub as before.
Now that I think of it, I wonder if issuing a cookie in a redirect header is
causing a problem? I checked the response headers, and it returns a 302
status code. Maybe I should change it to 303? Even if that is a problem, I
don't understand where or how the alleged caching is taking place.
