Updates find user by providerType and email-as-providerSubjectId (the state for a newly migrated user in ego v3 -> v4) to be case insensitive on email. Search on an updated providerSubjectId remains case-sensitive.
Add test for creating a new user when providerType is not default and providerSubjectId is set to email, but IDToken.email has different casing.
Add test for updating an existing user when providerType is default and providerSubjectId is set to email, but IDToken.email has different casing.
@joneubank @andricDu Iām not totally sure if the mocked mixed-case email tests Iāve added in the updateUser and createUser are entirely correct, i.e. if thereās an existing migrated user with username@domain.com in ego, and they log in with weird casing (USERname@domain.com), the IdP will still send whatever email they have associated with the acct on the IDToken sent to ego.
Updates find user by providerType and email-as-providerSubjectId (the state for a newly migrated user in ego v3 -> v4) to be case insensitive on email. Search on an updated providerSubjectId remains case-sensitive.
Add test for creating a new user when providerType is not default and providerSubjectId is set to email, but IDToken.email has different casing.
Add test for updating an existing user when providerType is default and providerSubjectId is set to email, but IDToken.email has different casing.
@joneubank @andricDu Iām not totally sure if the mocked mixed-case email tests Iāve added in the updateUser and createUser are entirely correct, i.e. if thereās an existing migrated user with
username@domain.comin ego, and they log in with weird casing (USERname@domain.com), the IdP will still send whatever email they have associated with the acct on the IDToken sent to ego.