You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 19, 2019. It is now read-only.
As raised in a comment on e978edd, we have extra information we wish to associate with a user which could be expressed via a custom user model.
We need to make sure the user model can accommodate "plain ol' users" which can log into, e.g., the admin but also users created implicitly via API authentications. Something like:
fromsome.moduleimportOAuth2TokenUser# can create user as beforeu1=OAuth2TokenUser.objects.get_or_create_user(username="some_admin")
assertu1.schemeisNoneassertu1.identifierisNoneassertu1.username=="some_admin"# can also create from token dictionarytoken= {
"sub": "mock:test0001",
# ...
}
u2=OAuth2TokenUser.objects.get_or_create_from_token(token)
# subject is a unique fieldassertu2.subject=="mock:test0001"assertu2.usernameisnotNone# (scheme, identifier) as a pair are a unique index in the DB.assertu2.scheme=="mock"assertu2.identifier=="test0001"
Ideally the username should be some unique value which is derived from the subject, perhaps something like:
importjsonfromhashlibimportsha256defusername_from_scheme_and_identifier(scheme, identifier):
h=sha256(json.dumps({"scheme": scheme, "identifier": identifier}))
return"{}-{}-{}".format(scheme, identifier, h.hexdigest()[:8])
defget_or_create_oauth2_token_user(token):
u=OAuth2TokenUser.objects.filter(subject=token['sub']).first()
ifuisnotNone:
returnuscheme, identifier=token['sub'].split(":")
# this method *must* call create_user or, otherwise, ensure that set_unusable_password()# is called on the objectreturnOAuth2TokenUser.objects.create_oauth2_token_user(
username=username_from_scheme_and_identifier(scheme, identifier),
subject=token['sub'], scheme=scheme, identifier=itentifier
)
As raised in a comment on e978edd, we have extra information we wish to associate with a user which could be expressed via a custom user model.
We need to make sure the user model can accommodate "plain ol' users" which can log into, e.g., the admin but also users created implicitly via API authentications. Something like:
Ideally the username should be some unique value which is derived from the subject, perhaps something like: