Space Admins Cannot administer space permissions

[DCITA IMO]

I am experiencing an issue where individuals or groups added as space admins to specific spaces do not have permissions to edit space permissions. It almost acts as if Confluence wants them to "authenticate" as a user yet they have no option to do that. Am I missing something? I have reviewed the documentation covering permissions and the differences between the various admin users and they should be able to edit space permissions yet are unable to do so. Any insight into a possible cause would be appreciated.

[Nic Brough -Adaptavist- · Accepted solution]

If a user has the tick against their name in the space permissions page for "admin" on the far right, then they should be able to change the permissions for that space - add/remove users and groups, and change those users check marks.

Do they have the "edit" button available when they're on that page?

[DCITA IMO]

Yes, they have the "Admin" tick checked (green) in permissions and they have the "Edit" button, however, when they click on the edit button then they get the error that they do not have permissions.

[Nic Brough -Adaptavist-]

Ok, if they didn't have the permission, the button shouldn't even appear.  Are they logged in with a non-expired session? (Easy to check, just go to another part of Confluence and check the user is shown as logged in at the top right)

Could you have a look at the log file at the point at which one of these users click the edit button?

[DCITA IMO]

Yes, they are logged in. I'll have a look at the log files and see if I can see anything pertaining to this issue. I'm also wondering if maybe this is a database issue.

[DCITA IMO]

Ok, we figured out what is going on here. When space admin clicks on "Edit Permissions" they are supposed to get the authentication page prior to them being dropped to the permissions editing page. What is happening is there are two special characters being inserted in the URL string that turns out OpenAM doesn't like. Specifically it is encoding the second set of 3 characters into a special character (a question mark). If we decode the second character and replace the special character with the decoded string, the URL works. OpenAM kicks back the URL because of the second special character.

Now my questions is, does the newest version of Confluence do this? We spoke with OpenAM and they report this is working as intended and only older versions of the  web client accept special characters. So why does Confluence encode certain characters strings as special characters and can this be changed?

[DCITA IMO]

Below is the URL being generated when a space admin clicks on the "Edit Permissions" button. Notice the second question mark in the URL. That's what OpenAM doesn't like. If we replace the question mark with it's decoded value of %3f it works just fine.

https://learn.dcita.edu/confluence/authenticate.action?destination=/spaces/editspacepermissions.action?key=SC&edit=Edit+Permissions

[Nic Brough -Adaptavist-]

That is, I'm afraid, a perfectly valid url, and one that works with other authentication systems.  It looks to me that the OpenAM user authentication has a bug in it - it should accept the second ? as a valid url.

[DCITA IMO]

Well, turns out this is a bug with OpenAM. Just got an update from our dev team who had a ticket open with the OpenAm dev team about this and they now confirm this is a bug that will be fixed in a future release. At first they were saying it wasn't a bug until our own devs found something related to this issue in their release notes.

Also I would like to correct my earlier posts and state that we were in fact ENCODING the special character and not decoding it. When it is encoded then OpenAM let's it load. Just as an FYI in case anyone else runs into this issue and needs a workaround.

Thank you for your help.