Gossamer Forum
Home : Products : DBMan : Customization :

Whoa!!! Secure password lookup has stopped working on two separate implementations!

Quote Reply
Whoa!!! Secure password lookup has stopped working on two separate implementations!
Hey, all. I need some help on this pretty urgently, and need to find out if anyone else is having this problem or if it is related to my service provider. I have been successfully using the secure password lookup mod by Carol for some time and it has apparently stopped working. The session IDs are now not being kept after signing in, and after examining the session ID files, I noticed that the $uid is not being written. I have not changed anything on either of these implementations in days, and so am somewhat confounded as to why they decided to go haywire tonight/this moring.

First thing: anybody else seeing this or just me?
Second: gotta quick fix?

------------------
The Immuatable Order of Modding
-=-=-=-=-=-=-=-
1. Read the FAQ, 2. Search the board, 2a. Search the board again, 3. ask the question, 4. back-up, 5. experiment, 6. rephrase question (or better yet, post solution to original question)

Quote Reply
Re: Whoa!!! Secure password lookup has stopped working on two separate implementations! In reply to
I don't know. I'd have to first have access to your site to see what's going on from the "outside." Then I'd probably have to look at your files.


------------------
JPD





Quote Reply
Re: Whoa!!! Secure password lookup has stopped working on two separate implementations! In reply to
Further update: commenting out in db.cgi
Code:
&auth_cleanup unless ($auth_no_authentication); # Remove old session files.
keeps the session ID, which seems to indicate where the problem lies...

------------------
The Immuatable Order of Modding
-=-=-=-=-=-=-=-
1. Read the FAQ, 2. Search the board, 2a. Search the board again, 3. ask the question, 4. back-up, 5. experiment, 6. rephrase question (or better yet, post solution to original question)



[This message has been edited by oldmoney (edited March 23, 2000).]
Quote Reply
Re: Whoa!!! Secure password lookup has stopped working on two separate implementations! In reply to
Carol: hope you're on West coast time Wink

Since you're online, in sub auth_check_password in auth.pl, what is *supposed* to be written from this line?
Code:
print AUTH "$uid: $ENV{'REMOTE_HOST'}\n";

I've never bothered to check the session files before since it worked first time otu of the box, but now I notcied that $uid is not defined anywhere and it is not writing anything. Why not use $userid?

In sub auth_cleanup in auth.pl, this seems to be the operative line.
Code:
if ((stat("$auth_dir/$file"))[9] + $auth_time < time) {

I'm not familiar with the stat function. Can you clue me in?

[This message has been edited by oldmoney (edited March 26, 2000).]
Quote Reply
Re: Whoa!!! Secure password lookup has stopped working on two separate implementations! In reply to
I've never looked at the session files either. Smile

Looks like the variable should be

$db_uid

instead of

$uid

Give that a try and see what happens.

I like your site. Smile I'm "into" genealogy, too.

I had no problem with using the password lookup. I signed up for an account, received my password and logged in just fine. Then I went back to the beginning, asked for a new password and got it. I logged in again with no problem.

Were you having any other problem, other than the session files?

(Yes, I'm on West Coast time. I live near Seattle. Smile )


------------------
JPD





Quote Reply
Re: Whoa!!! Secure password lookup has stopped working on two separate implementations! In reply to
Yep, you can login just fine (I should have said that)... the problem is you can't go to any DBman generated page (view_record, add_record, etc) without gettign an invalid session ID because the session ID file is immediately deleted (unless commented out like I mentioned above). After logging in, try going to Wedding Central (which is just a DBMan record pointing to a HTML file below the public_html level... e.g. root/private_html).

Yes, changing $uid to $db_uid writes the current session Id into the file (and changing it to $userid writes teh current user)... neither of which changes the automatic deletion of session files.



------------------
The Immuatable Order of Modding
-=-=-=-=-=-=-=-
1. Read the FAQ, 2. Search the board, 2a. Search the board again, 3. ask the question, 4. back-up, 5. experiment, 6. rephrase question (or better yet, post solution to original question)



[This message has been edited by oldmoney (edited March 24, 2000).]
Quote Reply
Re: Whoa!!! Secure password lookup has stopped working on two separate implementations! In reply to
Fortunately, I had opened a new window when I went to your site and it was still open. Smile

Have you checked to be sure the session files are being deleted immediately? (If not, log on and then look into your auth directory and see if there is a file that matches your session id. There should be one there right now that is
JPDeni.95388472034860 )

If there isn't one there, check to be sure that your auth directory has the right permissions -- 777 (rwxrwxrwx). It's possible that some server admin did something that changed your permissions.

The other thing is to look to your .cfg file and make sure that

$auth_time

is set to a big number.

I can't think of anything else off the top of my head that would cause this. I will continue to ponder, however.

(BTW, I like the look of your site. Smile )


------------------
JPD





Quote Reply
Re: Whoa!!! Secure password lookup has stopped working on two separate implementations! In reply to
Yep, no session file for jpdeni... it is immediately deleted the first time you try to "do something".. ie view/add/modify a record. Haven't touched the cfg file since setting up the DB, but $auth_time is set to 7200 (a couple hours).... auth directory permission had been 755, but I just checked and changing it to 777 doesn't fix.

I gotta come believe that this line
Code:
if ((stat("$auth_dir/$file"))[9] + $auth_time < time) {
is the problem... I'll go figure out what the stat function is for starters... for now, commenting out the auth_cleanup is a temporary fix... <sigh>

Thanks for your help... and thanks for the compliments on the site... it's not much especially since the genealogy stuff isn't even up yet! :P
Quote Reply
Re: Whoa!!! Secure password lookup has stopped working on two separate implementations! In reply to
stat(filename)[9] is the time at which the file was created, in Unix time. The line you quoted takes the time the file was created, adds the value of $auth_time and compares it to the current time.

I wonder if something is going on with time on your server. (I'm thinking about server problems a lot right now, because I spent about 4 hours last night trying to track down problems that ended up to be server-related. Smile )




------------------
JPD





Quote Reply
Re: Whoa!!! Secure password lookup has stopped working on two separate implementations! In reply to
Yeah, the server problem is most likely culprit, since it doesn't make sense that both implementations would stop working at the same time otherwise (BTW they are both hosted with 9netave/concentric-- mediocre provider at best IMO). Of course, Murphy's Law would naturally have me traveling out of town this morning, so I won't be able to *actually* fix the problem until this weekend. I appreciate your help and will post any resolution when I get back...

I noted in another thread that you like Gummy Bears... where should I send them? Email me with your coordinates, if you wish... Smile

------------------
The Immuatable Order of Modding
-=-=-=-=-=-=-=-
1. Read the FAQ, 2. Search the board, 2a. Search the board again, 3. ask the question, 4. back-up, 5. experiment, 6. rephrase question (or better yet, post solution to original question)

POST MORTEM: As suspected and seconded by Carol, my service provider changed the way files are time stamped (for some reason -8HRS from EST while the time function remains EST). Adding the appropriate number of seconds to this line
Code:
if (((stat("$auth_dir/$file"))[9] + $auth_time + 28800) < time) { # their server is 8 hours behind current time function
did the trick. Just letting others know if they are gripped by panic (like I was) at 2:30 in the morning...

[This message has been edited by oldmoney (edited March 26, 2000).]