New User Account Activation fails when, in the Global Configuration, New User Account Activation is set to "Admin" and when the "Access" level for the "Login" & "Register" menu items is set to "Guest".
The expected result is for the user account to be successfully activated.
If the "Login" page is restricted to guest, and the Super User is signed in, when trying to activate new accounts via the email the site administrator is sent, you will receive the error message "you are not authorized to view this resource".
If the Super User is not logged, they will be greeted with the message "Please log in to confirm that you are authorised to activate new accounts". Once you login, you are greeted with the error message "you are not authorized to view this resource".
php: Linux 3.10.0-962.3.2.lve1.5.27.el7.x86_64 #1 SMP Sat Nov 30 02:18:52 EST 2019 x86_64
dbserver: mysql
dbversion: 5.7.29-cll-lve
dbcollation: utf8_general_ci
dbconnectioncollation: utf8mb4_general_ci
phpversion: 7.3.13
server: Apache
sapi_name: fpm-fcgi
version: Joomla! 3.9.15 Stable [ Amani ] 27-January-2020 15:00 GMT
platform: Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
No extra extensions have been added. The site is a fresh install, done today, only running the Joomla core.
The goal is to only show the Login link for users who aren't signed in, and only show the Logout link for users that are.
If you set the Access level for the Login Menu Item to "Public" then Account Activation will work fine. However, this setup should also work.
The current setup use to work prior to the implementation of this:
https://developer.joomla.org/security-centre/754-20181004-core-acl-violation-in-com-users-for-the-admin-verification.html
This particular issue was discussed here:
https://issues.joomla.org/tracker/joomla-cms/22940
However, it was closed due to this PR being proposed #20282 but that PR has since been abandoned and is now outdated.
There was also a suggestion that the "Accepted Solution" in this topic on Stack Overflow worked, but if it worked, that is no longer the case.
https://stackoverflow.com/questions/34883387/joomla-3-4-8-logged-in-users-seeing-error-you-are-not-authorised-to-view-this-recource
At the bottom of the Stack Overflow topic mentioned above, another user proposed
With this setup for the "Login" menu item, if the Super User is not logged, they will be greeted with the message "Please log in to confirm that you are authorised to activate new accounts". Once you login, the account is successfully activated.
If however, the Super User is already signed in, when trying to activate new accounts via the email the site administrator is sent, you will receive the error message "you are not authorized to view this resource".
To fix this, the same thing needs to be done for the "Register" menu item as was done for the "Login" menu item.
With this setup for the "Register" menu item, if the Super User is already logged in when clicking the activation link contained in the email, the user account will be activated successfully.
This "Workaround" shouldn't be necessary. The accounts should be able to be activated with the initial setup without having to resort this.
Labels |
Added:
Information Required
|
Hello @richard67,
Thank you for the information. The workaround in that other ticket does in fact take care of the problem.
However, as @visualtribe suggested in that issue here, this is being done with the superuser account, so why should a "workaround" even be necessary?
It would be way more intuitive if the superuser accounts could do this normally without having to resort to a workaround.
This is also not documented anywhere and only came up after the ACL security fix was implemented.
https://developer.joomla.org/security-centre/754-20181004-core-acl-violation-in-com-users-for-the-admin-verification.html
The other ticket is closed, and if this ticket is also closed then there is no, to my knowledge, official ticket left open to track what seems to be a "flaw" in the logic of the ACL system.
Before this issue is closed, it would be nice to receive an official acknowledgement as to what the correct course of action should be here.
If this is what will be necessary going forward, then it should be documented somewhere, and a link added to the ticket for the documentation others to find.
If this issue should be fixed, then the issue should be left open so it can be acknowledged and tracked.
kind regards
This is also not documented anywhere and only came up after the ACL security fix was implemented.
https://developer.joomla.org/security-centre/754-20181004-core-acl-violation-in-com-users-for-the-admin-verification.htmlThe other ticket is closed, and if this ticket is also closed then there is no, to my knowledge, official ticket left open to track what seems to be a "flaw" in the logic of the ACL system.
Before this issue is closed, it would be nice to receive an official acknowledgement as to what the correct course of action should be here.
If this is what will be necessary going forward, then it should be documented somewhere, and a link added to the ticket for the documentation others to find.
If this issue should be fixed, then the issue should be left open so it can be acknowledged and tracked.
@wilsonge or @SniperSister or both: Could you have a look on it and comment about it?
@N8Solutions Well, if there still an issue then of course let it open here so we can keep track on. I'm just a normal contributor like you are, so I've pinged the experts to have a look on it and comment. Thanks for caring about Joomla!
Yes, I believe there is. I would think it only natural that a user with Superuser privileges should be able to activate an account with the setup described here without having to resort to a workaround. So thank you @richard67! I sincerely appreciate your help! The workaround provided in the other issue you linked to is more efficient and easier to implement until this gets resolved.
@N8Solutions Well, we are all volunteers here who love Joomla and have a bit time left, it doesn't need much ... and some of us like to code new things or fix things ... some others like to test fixes ... and we all like to help.
So if you love Joomla, too, and sometimes have a free minute, it would be very welcome if you could support us a bit. Maybe just read issues and comment with helpful comments, or test pull requests, whatever you feel welcome to do.
Is not a must ... but as I said, any kind of positive contribution is welcome.
P.S.: I thought about creating an award for the longest issue title ever ;-)
Status | New | ⇒ | Confirmed |
It is not a bug. If the Login menu item is set 'Guest' and Administrator or Super Admin is no selected in that user group they do not have access. That is to be expected.
If you want the Login menu item set at Guest level then you must select the Admin and Super Admin Users >>> Access levels ... Guest. Or redirect after login to a page that has a Level that allows Admin/super Admin.
It is not a bug. If the Login menu item is set 'Guest' and Administrator or Super Admin is no selected in that user group they do not have access. That is to be expected.
If you want the Login menu item set at Guest level then you must select the Admin and Super Admin Users >>> Access levels ... Guest. Or redirect after login to a page that has a Level that allows Admin/super Admin.
Yes, that's right. I should have read the description more carefully. Closing as expected behaviour.
Status | Confirmed | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-05-01 23:35:13 |
Closed_By | ⇒ | richard67 |
Maybe related issue #25033 . @N8Solutions Could you check if this is the same issue as you have and if the workaround mentioned here and described more in detail here works for you, and if the explanation provided here explains it to you? And after check please report back here if ok or not, and if ok close this issue. Thanks in advance.