Username being set to givenname for socialaccount login
I have a new mailman3 install setup with Okta as a social application. This is working well for logins and data comes through as expected, but for some reason the username is being set at to a lowercase version of the given_name. The Extra data on the social users in the admin interface looks good, so I don’t think it’s a problem with the attributes coming from Okta.
We have tried a number of variations on the below setting, but that all of them other than the default of “username” end up with the username being empty. ACCOUNT_USER_MODEL_USERNAME_FIELD = “email”
Any direction would be welcome.
Thank you!
On 9/22/21 11:22 AM, cfarley@iastate.edu wrote:
I have a new mailman3 install setup with Okta as a social application. This is working well for logins and data comes through as expected, but for some reason the username is being set at to a lowercase version of the given_name. The Extra data on the social users in the admin interface looks good, so I don’t think it’s a problem with the attributes coming from Okta.
We have tried a number of variations on the below setting, but that all of them other than the default of “username” end up with the username being empty. ACCOUNT_USER_MODEL_USERNAME_FIELD = “email”
Any direction would be welcome.
This is an issue for Django allauth <https://django-allauth.readthedocs.io/en/latest/index.html>. Mailman has no control over this. The username is part of Django's login and is not used by Mailman at all.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
- Mark Sapiro (mark@msapiro.net) [210922 20:46]:
On 9/22/21 11:22 AM, cfarley@iastate.edu wrote:
I have a new mailman3 install setup with Okta as a social application. This is working well for logins and data comes through as expected, but for some reason the username is being set at to a lowercase version of the given_name. The Extra data on the social users in the admin interface looks good, so I don’t think it’s a problem with the attributes coming from Okta.
We have tried a number of variations on the below setting, but that all of them other than the default of “username” end up with the username being empty. ACCOUNT_USER_MODEL_USERNAME_FIELD = “email”
Any direction would be welcome.
This is an issue for Django allauth <https://django-allauth.readthedocs.io/en/latest/index.html>. Mailman has no control over this. The username is part of Django's login and is not used by Mailman at all.
Does that mean, not having an user name would work for mailman? I always thought having an user name was required
Regards, Andi
On 9/22/21 12:13 PM, Andreas Barth wrote:
Does that mean, not having an user name would work for mailman? I always thought having an user name was required
Mailman core has no concept of username. Core understands users and addresses and both users and addresses have an associated display_name which can be any string or None, but this display_name is only text and is not required.
Django also has a concept of user and one can log in to Django either by address or user, but only the address relates to Mailman core.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 9/22/21 11:22 AM, cfarley@iastate.edu wrote:
I have a new mailman3 install setup with Okta as a social application. This is working well for logins and data comes through as expected, but for some reason the username is being set at to a lowercase version of the given_name. The Extra data on the social users in the admin interface looks good, so I don’t think it’s a problem with the attributes coming from Okta.
We have tried a number of variations on the below setting, but that all of them other than the default of “username” end up with the username being empty. ACCOUNT_USER_MODEL_USERNAME_FIELD = “email”
This setting actually specifies which field in your custom user model should be treated as username. From what I am seeing, you don't have a custom user model, so I don't think you want to override this field.
AFAIK, the username is picked by the Okta provider in django-allauth and it is a part of that integration betweek Okta and Django. If you look at the implementation of that integration, it doesn't set the username1, which (only some I am guessing) other providers do, Github for example2.
You can open an issue on django-allauth's Github page3 to ask them to update the Okta provider such that it also sets the username correctly like other providers.
-- thanks, Abhilash Raj (maxking)
participants (4)
-
Abhilash Raj -
Andreas Barth -
cfarley＠iastate.edu -
Mark Sapiro