Bad lastAccess check in SSCache::find
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
Environment
None
Activity
Show:
Scott Cantor July 5, 2016 at 2:51 PM
Thanks. I did a code review and I believe that all of the out of process calls to this find method are called with null in the timeout parameter, preventing the bug from fatally affecting current behavior. If that turns out to be wrong, we'll need to ship a patch update.
Rod Widdowson July 5, 2016 at 8:28 AM
5504c79
Fixed
Pinned fields
Click on the next to a field label to start pinning.
Details
Details
Assignee
Scott CantorReporter
Unidentified Legacy AccountComponents
Fix versions
Affects versions
Created July 5, 2016 at 5:33 AM
Updated June 24, 2021 at 2:05 PM
Resolved July 5, 2016 at 8:28 AM
Commit 92380630c4c151f5bf3205ed816a06ef018c52b2 to resolve https://shibboleth.atlassian.net/browse/SSPCPP-699#icft=SSPCPP-699 introduces a bad if-check on the lastAccess variable in shibsp/impl/StorageServiceSessionCache.cpp in the hunk starting at line 1623:
+ if (lastAccess = 0) { + m_log.error("session (ID: %s) did not report time of last access", key); + throw RetryableProfileException("Your session has expired, and you must re-authenticate."); + }This causes SSCache::find() to always report sessions as timed out if called from the shibd side and if given a timeout to enforce. I couldn't find any immediate cases that were affected, but custom handlers that people write may be (as is the case for me).