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.
We can now store IP ranges with Organizations. The aim is to have any user
logging in with a remote IP address within such a race will get the
organization roles assigned to the user object stored in the Flask session.
This commit just contains the MongoDB storage and querying, and not yet the
updates to the user.
This function ensures that the URL has the correct schema, given the
app configuration. This is required because the Flask instance can sit
behind an SSL-terminating proxy like HAProxy and not know that it is
reachable via HTTPS.
Instead of performing a call to the Blender Store, call to Blender ID to
get the user's subscription status.
Currently this is performed as a second HTTP call after logging in; in the
future we may want to include the roles in the login response from Blender
ID, so that we can do this in one call instead of two.
This 'custom view' means that the URL to view the node (as returned by
url_for_node(…)) cannot be loaded via XHR and embedded in the project
viewer, but should rather be used as the actual browser URL instead.
Currently only blogs use this.
This is quite a heavy thing to run, since it goes over all files of a
project, and then goes over every document in (almost) every collection
which has a property 'project' that's set to the project ID. It then goes
over every document to find all ObjectIDs and removes those from the set
of file ObjectIDs for that project. The remaining ObjectIDs are considered
orphans.
This is a very thorough search, but it doesn't require any knowledge of
the document and collection structure, so it should be future-proof.
This should be hidden in the UI as well, but the backend should support this too.
We also want to set initial rating of 1 for contents that need it.
This commit includes a new unittest for this case.
Reviewers: sybren
Differential Revision: https://developer.blender.org/D2825
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.
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.
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 produces a 'Vary: X-Requested-With' header on the response of
decorated view functions, which indicates to the browser (or intermediate
proxy servers) that the response may/will will be different for XHR and
non-XHR requests.
A class-based approach is easier to extend than the function-based approach
used in the nodes. That one is still there, though -- might look at it
at a later time. This handler is primarily for Flamenco.
This removes the ability of updating service accounts through the CLI
(something we never used anyway), now that service accounts cannot be
uniquely identified by their email address.
A PUT request on /api/user/{user-id} by the user themselves would allow
too much, and would allow self-granting of roles (including admin),
group membership (so join any arbitrary project) and pretend to be
service accounts.
