This also changes the way we treat Blender ID tokens. Before, the Blender ID
token was discarded and a random token was generated & stored. Now the
actual Blender ID token is stored.
The Facebook and Google OAuth code still uses the old approach of generating
a new token. Not sure what the added value is, though, because once the
Django session is gone there is nothing left to authenticate the user and
thus the random token is useless anyway.
String concatenation is bound to mess up; in this case it was producing
double slashes instead of single ones when `BLENDER_ID_ENDPOINT` ends in
a slash. Since URLs generally end in a slash, this should be supported.
Now BLENDER_ID_ENDPOINT is used for the Blender ID OAuth config,
and it's directly accessed when building requests for Blender ID token
validation (without using utility functions).
We perform authentication of the user while handling the request,
but Sentry calls get_user_info() in a before-request handler. This means
that Sentry would miss user info in many cases. This fixes that.
This is a two-stage approach that happens when a new token is verified
with Blender ID and stored in our local MongoDB:
- Given the remote IP address of the HTTP request, compute and store the
org roles in the token document.
- Recompute the user's roles based on their own roles, regular org roles,
and the roles stored in non-expired token documents.
This happens once per hour, since that's how long we store tokens in our
database.
Before this, authentication tokens were kept in the database, even when
someone logged out. This is unwanted behaviour, as logging in will create
yet another token anyway there is no reason to keep the token around.
Before this, the user's authentication token would still be stored in
the session even when it's found to be invalid. This caused a login
action to fail, but not in such a way that we would redirect to the login
page of Blender ID. Rather, it would keep you not logged in. By clearing
the session we're sure that the invalid token is forgotten, and the next
request will handle the login properly.
Setting flask_login.current_user ourselves was a bad idea, and messed up
flask_login's internal administration. Our code now just manages
g.current_user in these specific instances, which works fine.
- No more direct access to g.current_user, unless unavoidable.
- Using pillar.auth.current_user instead of g.current_user or
flask_login.current_user.
- p.a.current_user is never checked against None.
- p.a.current_user.is_authenticated or is_anonymous is used, and never
together with a negation (instead of 'not is_anon' use 'is_auth').
- No more accessing current_user a a dict.
- No more checks for admin role, use capability check instead.
Also added SERVER_NAME in config_testing and pre-populated the keys of OAUTH_CREDENTIALS, since the implementation of providers is part of the application.
This is an in-between change. In the future, we want to always set
g.current_user so that it's never None (but rather an AnonymousUser
instance). However, there is still some code that assumes that when
g.current_user is not None the user is logged in. This should be
addressed first.
Both approaches now use a pillar.auth.UserClass instance. g.current_user
is now always set to that instance, even for web entry points.
This UserClass instance can still be keyed like the old dict, but this is
for temporary compatibility and shouldn't be relied on in new or touched
code.
This message was "flashed" (http://flask.pocoo.org/docs/0.12/patterns/flashing/)
by Flask-Login. This happens on every unauthorised request, so also on
AJAX requests (like for the notifications). As a result, a user could be
spammed by a screen full of these messages if they left their window open
and their session timed out.
The 'manual fixups' are:
- incorrect use of dict.items() where dict.iteritems() was meant; this
results in list(dict.items()), which I changed to dict.items().
- removal of 'from __future__ import' lines, which 2to3 changes into
empty lines; I removed the empty lines.
