Log in, do something which will save something on the user state setUserState
Log out, log in to a new user. Try doing the same. When loading the page again the userstate will not be set
Expected result would be that the session registry
would be set and contain the user states.
When reading the session, getting registry
will return null.
This happens when you log out.
Windows 7 - dev
CentOS
Joomla 3.5.1
As a temporary fix I override the setUserState
method in libraries\cms\application\cms.php
to set the registry if it was null.
Not sure where to put the actual fix, but there could be some checks on the method afterSessionStart
to create the registry if it's null instead of only isNew()
The problem isn't that it's private for each user. The problem it that after you log out, it won't recreate the registry for the possible new user who logs in. So everytime you try to setUserState
after a logout, nothing will work because the session registry is null.
I can't believe that THAT is the expected behavior.
Don't have this issue on 3.6.0 Beta !
Hmm, I will do some more research and come back to the issue
Tested in the backend using the submenu on Articles. Switched between SU and an administrator. Setting the submenu to hide on SU, switch to other component and return to Articles. Log out, log in as administrator. State by default is Show, set it to Hide, go to different component and return to Articles: submenu is hidden. Log out, login as SU, state submenu is still as set just before log out. Same thing when logging back in to administrator. UserState works for submenu of Articles.
Labels |
Added:
?
|
Category | ⇒ | Libraries |
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-08-03 16:42:02 |
Closed_By | ⇒ | brianteeman |
Closed based on the comments above. If it is still an issue it can always be reopened
I'm getting the same problem on joomla3.6.2
after you log out, and then login, it won't recreate the registry into the session, so that setUserState and getUserState dont work.
My a temporary fix/workaround is to override setUserState and getUserState to avoid use registry.
someone found how to fix?
Confirm the issue in j362, request for reopening!
Status | Closed | ⇒ | New |
Closed_Date | 2016-08-03 16:42:08 | ⇒ | |
Closed_By | brianteeman | ⇒ |
Reopened as requested
I am having this same problem. Works correctly on joomla 3.5.1 but on 3.6.2 it behaves exactly as molteber and sarduk described. However I found that if I clear cookies in the browser then it fixes the problem. Of course that isn't something I can expect our users to do every time if fails but it may provide some insight into the problem.
I did some comparing for changes in the session handler between 3.6.0 and 3.6.2 and I found that in libraries/joomla/session/session.php, in the fork() method, there was this statement in 3.6.0:
// Kill session
$this->_handler->clear();
This is at approx. line 772 in the file. This statement was removed in 3.6.2. When I put that statement back in, it fixes the problem for me. Now I can log out and log back in again and the setUserState method now works as it should.
Now since I really don't understand the details here, I'm not advocating this as the "fix". However I am going to use it on my test system as at least a temporary work around until the final fix is provided.
@molteber is the Issue also on latest Staging?
Status | New | ⇒ | Information Required |
Status | Information Required | ⇒ | Closed - No Reply |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-05-27 09:54:57 |
Closed_By | ⇒ | franz-wohlkoenig |
Status | Closed - No Reply | ⇒ | Closed |
Closed_Date | 2017-05-27 09:54:57 | ⇒ | 2017-05-27 09:54:58 |
Closed_By | franz-wohlkoenig | ⇒ | joomla-cms-bot |
Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/10820
This has been closed due to lack of response to the requests above – it can always be reopened in the future if it is updated.
Can't consider that a fix. Current behaviour is as expected. The user state is private for each user. It doesn't effect different users. So, it works as designed!