Now settings live in a dedicated space, the settings blueprint can be used by Pillar applications, and the templates can be extended or overridden. Moved subscription and email settings to the blender-cloud repository.
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.
When a new user is created, two things happen:
- before inserting into MongoDB, the organizational roles are given
- after inserting, the organizations are updated to move the user from
`unknown_members` to `members`.
This actually returns an AnonymousUser object, instead of None, when the
user is not logged in.
For compatibility with existing code, this function doesn't set
g.current_user to that AnonymousUser instance. We may decide to do this
later.
With a PATCH request you can now:
- assign users,
- remove a user,
- edit the name, description, and website fields.
Only the organization admin user can do this.
This is a Flamenco/Attract-style Manager object that's instantiated by
the PillarApplication. It can create Organizations and assign/remove
users.
Also I updated the Organization schema to reflect the currently desired
design.
NOTA BENE: this does not include any security/authorisation checks on Eve's
organizations collection.
The stream_to_storage function is still quite large, and this is a first step at refactoring it. stream_to_storage can be used for files that are uploaded on the server without the /stream endpoint (for example downloaded from a link).
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.
