User tests: Successful: Unsuccessful:
@mbabker when you have a chance - please review my another code here, its related with closed PR #8834
It will fixed problem too.
description:
When session time was expired and we open site page, it getting data from expired session data which store in DB, so page has an old form token, and, after, expired data deletes from db here https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/application/cms.php#L758-L768, so next any pages have new token and, when we call ajax from page with old token, we get invalid token message, because user data session was recreated with new token.
Status | New | ⇒ | Pending |
Labels |
Added:
?
|
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-01-27 21:45:02 |
Closed_By | ⇒ | wilsonge |
Closing as what michael said is 100% true
No, no, no, no, no.
That delete code HAS to be there because of the extra metadata stored as part of the session, i.e. the bad design decision I've been groaning about all over this tracker. In truth, that query could be disabled in full if
$handler == 'database'
and left to the session API's garbage collection processing.Step two. The
checkSession()
method should only manipulate thetime
column when$handler != 'database'
. The time should ONLY be manipulated by the session API when the database is the session data store; outside manipulation of it (such as in the referenced method) is as good as invalidating an entire session's record to me.Maybe the second item fixes the problem you're running into. But what your first PR did is anything but valid and this second PR is adding some random check variable without any real explanation. Point blank, I have used this session API as part of a Framework application and the API itself behaves just fine. It's this damn metadata that is screwing things royally.