For info and debug level logging (basically: for all logging levels that might be disabled in production), it's better to use percent formatting.

logger.debug('Authenticated Blender Cloud user: %s', user)

This will only call str(user) and do the string formatting when debug-level logging is actually enabled.

I don't feel very strongly about this, though, so if you think the small performance cost is worth it to get more readable code, that's fine too.

I suspect this will happen quite a bit, when the Blender Cloud session expires (or when people log out, which I expect to happen less often). Is it necessary to send a warning to Sentry about this?

From the code, these looks like some mocked Flask classes, so that we can call Flask functions without actually creating a Flask app.
I think it's a good idea to document this, and to also include information on how these attributes were chosen; for example, "these are the app attributes used by classes A & B of Flask version X.Y". That'll make it easier to figure out what was happening at the time (there is nothing as permanent as a temporary fix ;-) ).

Where does the 31 days come from? Is this some sensible default? Or does it mirror settings of Blender Cloud?

This code has a race condition. If two requests come in at the same time, the above models.OAuthUserInfo.objects.get() call can raise a DoesNotExist exception, while at this point in the code the OAuthUserInfo has already been created by the other request.

This can create conflicts. We have had situations like this in Blender Store (BS) as well:

• BS has users for A@example.com and B@example.com
• BID only has user A@example.com
• On BID, user changes email to B@example.com, which triggers a webhook call on BS.
• BS can't make the change, because another user already exists with that email address.
• BS renews the user's Cloud subscription, sending a notification to BID to grant cloud-subscriber role to A@example.com
• BID cannot find the user, and returns an error.
• The user cannot use the subscription they paid for.

BS is a bit messier than Blender Studio, with more history (like not requiring BID in the past, so there are user accounts without BID), but still we should try and create code that at least expects these situations and has some graceful handling of it.

I know that there were some # TODO(Sybren): handle nickname conflict markers in the Blender ID OAuth Client code. Maybe it's enough to log the exception, and flash a message to the user notifying that they should check their email address? Or just contact us to clear things up? I think that would be an improvement over just showing a "500 internal error" screen, and it certainly would be an improvement over my TODO. Probably should be merged with similar conflict resolution in profiles/views/webhooks.py. For now I'm also fine with a TODO marker that indicates this, and to resolve it in a different patch.

How were these created?

We've had many issues with Blender Cloud messing up the redirect-after-login URL, where it redirected to / instead of the actual URL where the user requested the login. Having tests for next_after_login is great, but I think it should use a non-root URL to do this, or it could mask certain issues.

I think the self.assertFalse(User.objects.filter(email='jane@example.com').exists()) from test_middleware.py would be nice here too.

Please add some tests that reflect the email and nickname conflicts I described earlier, so that these are more explicit and also easier to fix later.

This comment doesn't quite make sense. To me it reads like "Keep role names the same, which means changing the role names".

There is no need to use sub-expressions here. This should do the same:

re.sub(r'^cloud_', '', name)

Precompile the regular expression. Right now it's compiled for every iteration of the loop. Having a global declaration like this would help:

_cloud_role_name_cleanup_re = re.compile('^cloud_')

You can also use a set comprehension here:

return {_cloud_role_name_cleanup_re.sub('', name) for name in names}

This is slightly more efficient than creating a generator expression and passing that to the set() function.

👍 for moving this code into its own function. The comment can go, though, as it just repeats the function name now ;-)
(same for the other appearances of the comment)

Woohoo! Mongo's gone!