Open MaxwellDPS opened 2 days ago
Thats strange ... The only strange thing I can see in the code is a loading with the email in lowercase versus a loading without case manipulation. I will try to reproduce.
After some testing, there is no problem, the query is not case sensitive. The code responsible for this is quite simple.
First we load the user to check if it exists. So in your case, the function return an empty value
const user = await elLoadBy(context, SYSTEM_USER, 'user_email', email, ENTITY_TYPE_USER);
if (!user) {
// If user doesn't exist, create it. Providers are trusted
const newUser = { name, firstname, lastname, user_email: email.toLowerCase(), external: true };
return addUser(context, SYSTEM_USER, newUser).then(() => {
// After user creation, reapply login to manage roles and groups
return loginFromProvider(userInfo, opts);
});
}
Because the return is empty, we try to create the user. As you can see the addUser function try to load the user first. Except the lowercasing, its exactly the same call. In your case this time the load function return a result and so the addUser function reject the execution.
export const addUser = async (context, user, newUser) => {
const userEmail = newUser.user_email.toLowerCase();
const existingUser = await elLoadBy(context, SYSTEM_USER, 'user_email', userEmail, ENTITY_TYPE_USER);
if (existingUser) {
throw FunctionalError('User already exists', { user_id: existingUser.internal_id });
}
...
}
Maybe something with the mappings and the keyword definition
Description
Following a re-index and upgrade to 6.3.6 no users can not auth via pre-existing SSO
Environment
Reproducible Steps
Steps to create the smallest reproducible scenario:
Expected Output
Successful login session
Actual Output
Redirects to the login page
Additional information