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.
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.
Refactor of pillar-server and pillar-web into a single python package. This
simplifies the overall architecture of pillar applications.
Special thanks @sybren and @venomgfx
