Forum OpenACS Q&A: Cookies not staying after I close my browser

Hi OpenACS Team,

My login cookies don't stay after I close my browser.  I can't figure
out what I did wrong.  Do you guys have any ideas?

I'm running the latest release of OpenACS.  Thanks!

Gilbert

PS.  I have some free time.  Do you guys need help porting ACS 4.0?

Collapse
Posted by Ben Adida on
Are you using the "remember me" feature? Just
double-checking.
Collapse
Posted by Gilbert Wong on
Ben,

Yes I am.  I also have the allow persistent login set in the .ini file in the parameters directory.  The behavior is very odd.  I was going to do some more investigation but I wanted to make sure that there were no outstanding bugs.  I must have configured something incorrectly.  If you have any suggestions as to where I should look, please let me know.  I'll let you guys know if I find out what is going on.  Thanks.

Collapse
Posted by Ryan Lee on
Just sounding off that I've run into the same problem.  I've been digging a little in my spare time, but don't have anything useful to add.  The behavior occurs with a fresh OpenACS 3.2.4 install and still occurs even with the latest sourceforge /tcl/ad-security.tcl
Collapse
Posted by Gilbert Wong on
If anyone wants to see this behavior, try logging into anime.orchardlabs.com.  Then close your browser and return to the site.  You shouldn't be able to access /pvt/home without logging in again.

The odd thing is that my development server on my internal network does NOT display this behavior.  I'm baffled.

Gilbert

Collapse
Posted by Ryan Lee on
I take it back. It's not from a fresh install. Gilbert, do you have database passwords set to be encrypted? Because I do, and that's the source of the problem. Take out the
if { [ad_parameter EncryptPasswordsInDBP "" 0] } {
    set password [ns_crypt $password [ad_crypt_salt]]
}
block on line 238 of ad-security.tcl. This block is essentially saying "if the passwords are encrypted in the database, then encrypt the hexified password from the cookie (ad_user_login)." The only problem being that the hexified password is already the hexified encrypted password.

So what the session_id setter is trying to do is match the dehexified encrypted hexified encrypted password to the encrypted password from the database. Obviously those two won't be equal, so it assumes you're not logged in and proceeds accordingly.

Hope that wasn't too cryptic. Mine works now :)

Collapse
Posted by Ryan Lee on
Oops, that's line 283, not line 238.
Collapse
Posted by Gilbert Wong on
Ryan,

Thanks.  That was the next thing I was going to check :)  My dev box doesn't use crypted passwords.  I'll make the necessary changes.  Thanks!!!

I recently noticed a difference in the way IE5 &
Netscape handle cookies. Netscape does not seem to
require the domain name of the server whereas IE5 does.
But ... on a development machine (localhost) neither
browser seems to care.

I went round & round with this recently.
Be advised though, I'm just learning this stuff.