[MGNLSSO-73] Username is randomly modified that makes it unreadable Created: 26/Jul/21 Updated: 08/Sep/23 Resolved: 27/Oct/21 |
|
| Status: | Closed |
| Project: | Single Sign On |
| Component/s: | None |
| Affects Version/s: | 2.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Boris Faniuk | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||
| Description |
|
Steps
Actual Expected Development Note |
| Comments |
| Comment by Maxime Michel [ 27/Oct/21 ] |
|
Closing because it appears superseded by |
| Comment by Maxime Michel [ 27/Oct/21 ] |
Thank you for bringing this up. In such a case, we have a difference with the baked in security interface (you mean Security app, right?) and the ExternalUserManager being used by the module. Because such characters in its username actually prevent the user from logging in when using the SSO module. This is the reason we filter them out out of the box, in the case where the IDP ships an email as user ID. |
| Comment by Boris Faniuk [ 27/Oct/21 ] |
|
Hello! You're right, that both
Can you please give a bit more details on this. Map<String, String> userDetails = Map.of(NAME, profile.getDisplayName()); So, NAME attribute is not a good alphanumeric value and we had no complains yet. |
| Comment by Maxime Michel [ 28/Oct/21 ] |
|
Hi bfaniuk, it has been a while since I last ran into this. Now that I think about it, it might be that it's the user ID rather than display name that doesn't tolerate special characters. In any case, you shouldn't worry about side-effects, no. When this issue happens, the user is faced with a blank page after login and it's immediately obvious something is not right. Now that it's possible to have different UserDetailsProvider, though, I will file a follow-up so that default implementations are available for Azure, Okta, Keycloak, etc. Those would be more efficient at solving each individual case based on available fields than the default all-around solution. Best, |