[#5086] - Implementing a clearAccessRights method
- Closed
- 10 Dec 2014
- Medium
- Build: staging
- # 5086
- Diff
- Hackwar:fix_access_cache_clear
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
This PR implements a method that clears the access rights cache of the current JUser object. This is meant to help websites that sell memberships. Up till now, they had to process the payment of the currently logged in user, add that user to the new usergroups (which changes all his access rights) and then log out the user and force him to login again. This method allows you to change the access rights for this current user, clear the cached results and then for all new requests to the ACL system, you get the fresh data.
This does NOT work in circumstances where the admin changes the usergroups hierarchy around or changes permissions at one point. In that case, all users have to be logged out and actually all sessions have to be deleted once, before those changes take effect everywhere! There is no way around that.
Testinstructions:
- Write a component com_test with the following test.php:
<?php
var_dump(JFactory::getUser());
if(JRequest::getVar('clear')) JFactory::getUser()->clearAccessRights();- Login to the frontend, call /index.php?option=com_test, see the output.
- Go into the backend and change the ACL, reload the page in the frontend and see that nothing changed.
- Open /index.php?option=com_test&clear=1 and then /index.php?option=com_test and see that the new changes have taken effect.
This is related to #4991
jissues-bot
- | Labels |
Added:
?
|
||
No, this is not usefull, because this ONLY works for the currently logged in user. So Joomla can clear the cache of the user that is currently requesting the page (for example the admin user that changes the ACL permissions.) It can NOT clear the cache of a user that you are currently editing.
What this does is clearing the properties of the JUser object that cache the access rights. This means that it is later serialized and then written to the session storage again. When the user requests the next page, the JUser object is unserialized again and those caches are restored.
That is also the reason why we can't reliably do this for other users than the current one. If the session storage is not the DB or the data is encrypted, there is no way for us to reach that data at all and to modify it. Besides that, it would require us to somehow deserialize that data and afaik the session storage uses a different format than just serialize()/deserialize().
Ah I see.
So to make this clear to me if nothing else. If the user is making a subscription (which is probably the most used case for this feature) in the frontend where they are paying etc. It will update for them as the logged in user. If an admin does it in the backend they still need to log back out and in again for the changes to take effect?
brianteeman
- | Category | ⇒ | ACL |
As this isn't really testable inside the CMS but is clearly correct merging this.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-12-10 03:11:49 |
just an FYI that we have to adress in the next few days: This method has side-effects. Namely that at least in my case, it logs you out of Joomla. 
Will look into this further.
Would that be something useful to implement in our user manager? We could just clear the cache during saving of a user, I don't think it's worth the effort of comparing if the usergroups have changed.
What do you think? It would make this even easier to test and would be a win for the CMS as well as I understand it.