[#21230] - Fix for 403 error on session timeout Updated #15839
- Closed
- 21 Jul 2019
- Medium
- Build: staging
- # 21230
- Diff
- durubayram:staging
- Success Hound No violations found. Woof! Details
- Success continuous-integration/drone/pr the build was successful Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Failure continuous-integration/appveyor/pr AppVeyor build failed Details
- Pending JTracker/HumanTestResults Human Test Results: 1 Successful 1 Failed. Details
User tests: Successful: Unsuccessful:
Pull Request for Issue #15839
Steps to reproduce the issue
- Create a menu link to a single article with Access set to Registered (e.g. /test)
- Enable System - Language Filter plugin
- Go to System -> Global configuration -> System
- Set the Session Lifetime to 1 minute
- Save the change
- Login on frontend with "Remember me" checkbox ticked
- Wait 1 minutes for session to expire ;)
- Visit the protected page (e.g. /en/test)
- You get a message saying you are not authorized to view the page
- Apply the patch
- Login on frontend with "Remember me" checkbox ticked
- Wait 1 minutes for session to expire ;)
- Visit the protected page (e.g. /en/test)
#Expected result
You should be automatically logged in and land on open protected page.
Actual result
You are redirected to frontpage with message:
Error: You are not authorised to view this resource.
If your homepage requires access then you end up on 403 page.
System information (as much as possible)
What happens is that the language filter plugin builds the menu with access levels before the remember plugin had a chance to login the user. The menu is built with access levels of the guest user and updates only on refresh. So, on first visit, after the session expires, the menu thinks it's a guest and denies the access.
The quick fix is to re-build the menu after the remember plugin has logged in the user.
Here is the Gist, line 66: https://gist.github.com/sakicnet/f2b8e2486011093d08e544423d8e5124
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Libraries Front End Plugins |
Please update the original post with a description of the issue and instructions on how to test and please give it a meaningful title.
Also we assume that you wont submit none working code so there is no need (or meaning) in submitting test results yourself
| Title |
|
||||||
| Title |
|
||||||
| Labels |
Added:
?
|
||
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21230.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21230.
| Status | Pending | ⇒ | Ready to Commit |
Ready to Commit after two successful tests.
There is no way this can be RTC. The added setUser() method is on the JHtmlMenu class, which is NOT what you get when calling Joomla\CMS\Application\CMSApplication::getMenu().
| Status | Ready to Commit | ⇒ | Pending |
Removed RTC as stated.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21230.
@fatmaakay @priiish Your tests were not correct I am afraid as you should have seen a fatal error. Now with the updated code, please test again and follow the instructions step by step.
I have tested this item
This time it works and no error either in languagefilter.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21230.
@infograf768 will test at Weekend.
Can't get Error, i stay logged in after a few Minutes if i click on Menu having ACL "Registered". Language Filter-Plugin is enabled and in Frontend-Login "Remeber me" is ticked. Session Timeout seems to work only in Backend.
[Edit]: I used "Working on Your Site"-Menu in Author-Menu changed to Access "Registered".
@franz-wohlkoenig You don't get any timeout on your front-end?
@franz-wohlkoenig That must be another issue then, because the timeout should work regardless of this PR.
i thought its another cloudaccess-Issue.
@franz-wohlkoenig
Have you deleted the session in the table?
No, have followed Instructions.
Wait 1 minutes for session to expire ;)
I would definitely make sure the sesion is deleted. :)
Then i suggest that this Information should be added to Instructions as not all Tester have the Knowledge what to do or which table is meant.
If the only way is to delete them.from.yhe database.then there is something wrong
I tested the timeout and I am logged out once the time is expired.
I have tested this item
Against the current staging branch I cannot reproduce the issue as described in the description. So at the moment it looks like this patch is not needed (or the instruction to reproduce this should be updated).
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21230.
We are experiencing the problem described by durubayram, as indicated until step 9 in the first post. We have a multi-language site, and we are getting the "You are not authorized" error all the time.
However, we tested the patch c7eab13, but it didn't seem to fix the issue.
We are interested in fixing this issue, but I'm afraid I can't contribute to it as I'm not a programmer myself. I'm very happy however to run new tests or help in other ways to fix it.
(First post here on Github, please excuse if there's something wrong)
@HLeithner can you please decide how to go on?
seems this pr doesn't solve the problem completely, maybe @sanderpotjer can help fixing it?
I suggest to close this PR due the lack of response. In the meantime i add the label "needs new owner".
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-07-21 05:05:35 |
| Closed_By | ⇒ | franz-wohlkoenig |
This solved the problem for me also. Will this be added to Joomla production version anytime? In 3.9.14 still missing.
Why is this not added to Joomla core? Above mentioned changes to AbstractMenu.php and remember.php solved issues on all my sites and appearently also for other people. Pretty annoying to hack the core files after every update.
These changes were incorporated into the 3.9.20 release but did not fix the problem. Oddly, applying these fixes to the 3.9.19 release fixed the problem, but the problem reappeared with the 3.9.20 release. The above fix worked on all my sites for 3.9.19 but the base 3.9.20 fails in the original manner on all.
These changes are not present in 3.9.20.
Damn, these changes fixed the issue for 3.9.19, but applying the same changes to 3.9.20 doesn't eliminate the problem anymore. That is a real showstopper when users get "Error 403" all the time. This is a really serious thing for me :(
The changes fix it for me on both 3.9.20 and 3.9.21 (no changes in either module between these releases). I was seeing it all the time, and it's been gone since I applied these.
Thank for reply. I made a stupid mistake twice applying it to 3.9.20 :) It indeed works. It's a pity that the fix still hasn't made into the Joomla core.
I have tested this item✅ successfully on cee4dfd
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/21230.