403 Access Denied to Admin GCL and ACL

[daveej]

I have a problem that appears to have been referred to in a past solved post. I didn't get a reply post in the [Solved] item, so I'm reposting were it would belongs today.

This appears to refer to this post:
[Solved] 403 Access Denied while adding a new admin user.

Postby wtfnowagain » Thu Dec 26, 2013 12:13 pm


Here is my repost.

Postby daveej » Sun Feb 18, 2018 5:58 pm
I'm having a similar problem. I tried to change a user group to allow access the backend and enter new members. I couldn't find a solution without giving Superuser status. After testing and deciding this wasn't wise, backed off and tried to remove Superuser status. Now however I get as the only remaining Superuser:
Error
An error has occurred.
403 You are not authorised to view this resource.
when trying to change or add a User Group or Access Level.

And I can't do a restoration in Akeeba Backup. There are no admin buttons accessible in Akeeba Admin now, so I can't get to settings.

What do I do now?

[sozzled]

I have a problem that appears to have been referred to in a past solved post.

Where might this have been?

By the way, what is "GCL"? I'm not familiar with the acronym.

[daveej]

[Solved] topic is here: viewtopic.php?f=708&t=830632

I borrowed the ACL acronym and applied it to User Group. I tried modifying a user to allow Superuser privileges in Global Configuration and then changed it back. That broke my access to both User Group and ACL in the Admin backend.

[sozzled]

There's no shame in admitting one's goofs—I do it all the time If you want to grant another user superuser access to your website, you don't tamper with the ACLs; you use the User Manager and add the user account to the superuser group (but you didn't do that). By the way, using techiques may have appropriate to a situation four-and-a-bit years ago could be risky and that's probably what landed you in the strife you're in today.

Do you want the quickest, effective solution in your situation or do you want to roll up your sleeves and attempt to unravel the mess?

[daveej]

I have a back up that will fix it I know, but its a week old and I will wipe out a couple of users inputs. Yet this is an avocation, I work more than FT, so I don't have much time to do this.

I would like to fix it without undoing things, but if I'm taking on a huge project, I don't want to do that.

Its hard to believe that the only people who can change the Admin backend have to be superusers. I would think there would be a built in hierarchy of Admins, with the superuser in charge.

I greatly appreciate your help!

[sozzled]

I have a back up that will fix it I know, but its a week old and I will wipe out a couple of users inputs ...

It's probably a small penalty to pay for making a mistake.

It's hard to believe that the only people who can change the Admin backend have to be superusers.

Well, that's not entirely true. In the hierarchy of site administration there are (from most- to least-privileged) superusers, administrators and managers; their respective roles are described in the Joomla documentation website. Additionally to those "pre-packaged" roles, there are ways to extend certain administrator-like functionality to a whole range of people; the extensibility of privileged functionality (via ACLs) is virtually limitless but it does require a cautious, judicious approach in making those changes.

If it were my website, I would probably experiment with changing ACLs on a test site where it didn't matter if I goofed. Once I was confident that I knew exactly what I was doing and I could undo any accidental damage I might cause to a production site, that's when I would apply that knowledge to a real-life situation. Anyway, what's done is done but the situation is retrievable. Cheers.