Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.7.10
-
None
-
None
Description
When a user successfully changes their password the system creates a new SESSION_ID but it is never used. The session_ID is never sent in any messages it is only filed in the table which is why it is referred to as "internal" in the title of this issue.
Normally the EXPIRED_DATE of a SESSION_ID is set for the same date and 30 minutes past the ENTRY_DATE. However when the password is changed and the new session started the EXPIRED_DATE is set to expire to about 57 years in the future instead of 30 minutes.
This only happens when changing the password. The Expired_Date is getting set correctly and expiring for all other scenarios.
Again, this SESSION_ID is never used and is never sent in any xml messages. The only way to see it is to query the table directly, in which case you would need the appropriate access to the i2b2 database.
Normally the EXPIRED_DATE of a SESSION_ID is set for the same date and 30 minutes past the ENTRY_DATE. However when the password is changed and the new session started the EXPIRED_DATE is set to expire to about 57 years in the future instead of 30 minutes.
This only happens when changing the password. The Expired_Date is getting set correctly and expiring for all other scenarios.
Again, this SESSION_ID is never used and is never sent in any xml messages. The only way to see it is to query the table directly, in which case you would need the appropriate access to the i2b2 database.