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
We ran into an issue with connecting our SSO (Okta OIDC) provider where email address contained characters unsupported in the username (in this case it was an apostrophe). Eg.
CreateUser: name is invalid [Tim.O'Neill]: must be valid alpha or numeric or dash(-_) or dot characters
The user receives an ambiguous 500 error, but an admin needs to check the logs to find the error above
Technically, we also support ., so we should include that in the error string, and also we don't support sequential or leading/trailing non-alphanumeric characters
Since the set of allowable email characters is greater than gitea usernames, it can be pretty frustrating to configure for users (especially where this could be outside of the responsibility of gitea admins)
The top two issues are pretty straightforward, but I'm posting here to see if anyone has thoughts on the issue of handling unsupported characters.
Could we increase the allowed set of username characters? This would probably be a large lift, but I wonder if there are any true roadblocks. Of course, usernames are used in URIs, but can that be URIEncoded/escaped?
GitHub normalizes the input, essentially replacing non-supported characters with dashes. This is certainly an easier solution. There is (IMO) a slightly better implementation at SourceGraph.
If we went with the second option we could add a new [oauth2_client] USERNAME config option, like email-normalized. Alternatively, we could have some kind of setting for replacement characters to let the gitea admins configure what characters get replaced with what.
Gitea Version
1.20
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Local hosting
Database
None
The text was updated successfully, but these errors were encountered:
Note some relevant notes from Discord:
KN4CK3R —
What is the benefit of configuring the replacement?
kdumont —
Better accessibility so that gitea admins can work with users to find the most appropriate replacements for the user names. For instance, in my case above the ' is probably best omitted (whereas if we followed GH rules it would be replaced with -, so the name would be Tim.O-Neill. I could see that being frustrating for a user to see. Moreso, if users have special characters, like Schäfer could at least be Schafer (such as here: #11522).
However, I totally acknowledge this might be too much complexity.
KN4CK3R —
or use a special parsable string like ä,a;',;ü,ue
or better, add it to the auth source
there we could use a json config
and you can have different settings per source
but I see that as a follow up PR after implementing the "replace everythin with -"
Description
We ran into an issue with connecting our SSO (Okta OIDC) provider where email address contained characters unsupported in the username (in this case it was an apostrophe). Eg.
CreateUser: name is invalid [Tim.O'Neill]: must be valid alpha or numeric or dash(-_) or dot characters
There are quite a few related issues that've been reported:
#4030
#11522
#4434
#5444
#28288
#17757
#20422
It seems there are a few problems here:
The top two issues are pretty straightforward, but I'm posting here to see if anyone has thoughts on the issue of handling unsupported characters.
If we went with the second option we could add a new [oauth2_client] USERNAME config option, like email-normalized. Alternatively, we could have some kind of setting for replacement characters to let the gitea admins configure what characters get replaced with what.
Gitea Version
1.20
Can you reproduce the bug on the Gitea demo site?
Yes
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Local hosting
Database
None
The text was updated successfully, but these errors were encountered: