Forum OpenACS Q&A: Password expiration
To be sure I also set the AllowPersistentLoginP and DefaultPersistentLoginP to 0, then I logged out and set the password_changed_date on the users table one year in the past.
I restarted the server and after logging in I was correctly asked to change my password and to log in with the new password, but after logging in I wasked to change my password again.
If I restart the server I can log in without problem and so I suspect this is a caching problem.
The following are the relevant software versions:
Database: PostgreSQL 13.4 (Debian 13.4-3) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.3.0-8) 10.3.0, 64-bit
Server: 4.99.19 (NaviServer)
acs-kernel: 2017-08-06, 5.9.2d2
xotcl-core: 2017-08-06, 5.9.1
Thanks in advance for any suggestion.
This is useful to avoid repeatedly reading the users table, but when during login the proc auth::check_local_account_status compares the password_age_days with PasswordExpirationDays it uses the cached value and leads to a loop.
The proc auth::check_local_account_status is the only point where the password age is checked and is only used during the login and so I simply reread password_age_days:
set password_age_days [db_string reread "
select trunc(date_part('epoch', age(password_changed_date))/(60*60*24))
where user_id = :user_id"]
One reason for not getting immediate feedback is that you are asking a question about an old release, that we have not around anymore in action. Many things have changed in the user management in 5.10 (Antonio cleaned up much of this, the usage of
util_memoize was greatly reduced for scalability reasons).
The second reason is that you are directly modifying a value in the database, which causes very likely cache inconsistency. This is no usage scenario of the system. The proper call after changing user data in the DB is to issue
acs_user::flush_user_info -user_id $user_id
In case you want to support this kind of direct updates to the DB for
user_ids in your system, you might consider adding this line to
auth::get_local_account_status, that's better than duplicating this logic.
I missed acs_user::flush_user_info -user_id $user_id.
Actually I didn't change the database, but I simply added one line to auth::check_local_account_status rereading password_age_days from the users table.