Bug 823740

Note that the existing scheme should already automatically flag a user as an administrator based on the [admin] section in site.conf if they haven't logged into the site before.

It's only the case where someone changes from being a normal user to an admin user that currently requires a manual workaround:

1. Log into the site as an existing admin user
2. Click on the Site Admin link
3. Use the Django Admin UI to find the User entry for the new administrator
4. Change their status to mark them as a staff member and super user

I agree that this is annoying and the authentication backend should just update their user status automatically next time they log in, but it shouldn't be a blocker for anything.

The auto update will be in place for 0.0.16, but running a staging instance on 0.0.15 should be quite feasible.

As a potentially simpler workaround, it's possible to nuke all existing user entries, so they get recreated based on site.conf at next login:

$ python -m pulpdist.manage_site dbshell
SQLite version 3.6.20
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> delete from auth_user;

The recreation of the user with the correct permissions will then happen automatically next time the user logs in.

Dynamic updates have been added for 0.0.16, but it's still necessary to clear any active Django sessions to ensure that affected users are reauthenticated even if they have been logged into the web UI recently.

The relevant command is:

echo "delete from django_session;" | sudo python -m globalsync.manage_site dbshell

Leaving as modified until docs have been updated appropriately.

Rather than adjusting the docs, pulpdist-httpd has been updated to use memory backed sessions instead of database backed ones. This means restarting the web server will automatically drop any sessions, ensuring that permissions changes are picked up immediately.

The assumed use of Kerberos authentication with pulpdist-httpd means that end users shouldn't notice anything. For other usage scenarios, people can consult the Django docs to decide for themselves how they want to handle authentication, sessions, permissions and caching.