Forum OpenACS Development: Effect of LoginTimeout parameter on non-permanent cookies

Hi

I'm trying to understand the behaviour of non-permanent cookies in OpenACS, and hoping someone can clarify. This behaviour may well be different in the latest OpenACS so my apologies if it is, but from looking at the API Doc here on openacs.org and also on cvs.openacs.org it still appears to be the case. It appears that the kernel parameter LoginTimeout is used for 2 different purposes, which may be at odds with one another.

The parameter description is "The maximum number of seconds to let users stay logged in without requiring them to refresh their password. 0 for infinite. Requires a restart of the server to take effect."
At server startup, in packages/acs-tcl/tcl/security-init.tcl a proc sec_login_timeout is defined which returns the value of the LoginTimeout parameter.

sec_login_timeout gets called in 2 different places in OpenACS.

Case 1 is in sec_login_handler which checks the expiry on the cookie. This looks fine to me.

Case 2 however is confusing to me.
In https://openacs.org/api-doc/proc-view?proc=ad_user_login&source_p=1 for non-permanent cookies, we set max_age = to the value of [sec_login_timeout]. However sec_login_timeout will return 0 if the value of kernel parameter LoginTimeout = 0.
This has the effect of immediately expiring the cookie.

Is this the intended behaviour? Might there be a case where we don't want the cookie to expire immediately (while still allowing users to never refresh their passwords)? I think it's a little confusing that the parameter is used in 2 different ways.

thanks
Brian

Dear Brian,

ad_user_login will eventually call ad_set_signed_cookie.

If you check the code https://openacs.org/api-doc/proc-view?proc=ad_set_signed_cookie&source_p=1, there is actually an explicit reference to the "0" value, so that it will behave exactly as "Inf" concerning the validity of the cookie.

Do I understand correctly your question, or am I missing something?

Ciao

Antonio

Ciao Antonio

grazie mille! Yes, that explains everything. That change isn't in our older code base and I didn't think to check that proc in the latest versions. Problem solved.

Thanks again
Brian