We’ve been holding off using Cosign/EASE on our EdWeb distro site, until we had a clear solution to the issue of how to become the Drupal admin user (user=1). As soon as we turn on Cosign authentication, then we’ll only ever be able to be user UUN. Even if we created functional accounts (to use IS parlance), then due to our automatic authentication via browsers on DICE, it isn’t very convenient to become anyone other than our UUN. Also, on principle, we don’t have accounts in our authentication service that aren’t associated with an actual individual.
Asking around it sounded like there were two options people used:
- Just don’t sweat it, and use drush from the command line to do all your admin type duties.
- Either give yourself (or a functional account) all the available drupal permissions, so you can do everything.
Not being that fluent with drush, and that our web editors wouldn’t have necessary command line access to the server, 1. didn’t seem the best solution. Options 2 has problems, as the EdWeb developers are a bit wary of this and are not making any guarantees (in fact more likely the opposite) that we wouldn’t be storing up problems if user regularly published with all permissions granted.
So what we’ve decided to do is something a bit like a blend of the two options above.
Our solution
Ceate a new “admin user” role:
drush role-create 'admin user'
Give the existing EdWeb role “system administrator” a couple of extra
permissions:
drush role-add-perm "system administrator" "administer permissions" drush role-add-perm "system administrator" "administer users"
The “system administrator” role is already one that should only be given to a few select people who know what they are doing. Generally people will not have this role.
Then as one of those users who is a “system administrator”, via the web GUI, give the new “admin user” role all the other permissions with a couple of mouse clicks, excluding the “bypass …” permissions.
The above steps should only need to be done once to get things set up.
Now if any of the existing “system administrators” need to do something as the admin (user=1) person, then they can temporarily give themselves the “admin user” role, do what we need to do, and then remove the role from themselves once they are done. They should know not to create or modify content with the “admin user” role, but if they did, then hopefully by not having the “bypass …” permissions, things would be OK, but we shouldn’t rely on that.
As I write this, I might look at adding a block that only shows up when you have the “admin user” role, to remind you that you are (nearly) all powerful.
It’s a bit of a faff to have to add and then remove the “admin user” role, but luckily the times you need to be user=1 is fairly rare. And probably just as much as a faff if we were to do thing via functional accounts.
Notes
The suggestion to not grant the “bypass …” permissions came from Mairi. In an email/slack post she said:
On the subject of the ‘bypass content access control’ permission, the problem is that because permissions are being bypassed, you wouldn’t necessarily know which hooks are firing & which aren’t. Bypassing permissions will just invisibly allow the user to do anything, with no indication of whether data integrity is OK until something goes wrong. For example, we believe it’s probably OK to publish as user 1, provided that user is configured with relevant group memberships; however, we advise against it because nothing will tell you, when logged in as user 1, that the group hooks are actually firing. Which leads to unforeseen consequences when content is inadvertently created/published without the correct permissions being in place. If you give another user those ‘bypass’ permissions, the same will apply – i.e. that user could be publishing content without the correct hooks firing.
She also pointed me at this article from Stanford https://drupaltraining.stanford.edu/node/13.
Neil
