New database connection user can't log in (and other issues)

Help
,
1

I just created a new database connection with a new user and I can’t, for the life of me, figure out why it keeps giving me a “wrong user name or password” response when I try logging in.

I’m using the auth extension for RBAC and have a few rules that get run. I authorized the connection for the app and the auth extension (not sure it needed both). I have another DB connection that I created several months ago the same way that seems to be working fine, but I can’t get this new connection working no matter what I try.

When I try to debug using the logger, I tried dumping the user object to see if the roles I assigned in the auth extension were being applied – and they’re not there. I’m not entirely sure what other options there are…?

Related, but separate – how do I set it up so that this new user has to change their password on first log in? I’m really surprised some of the common/simple use cases like this aren’t just simple check boxes in the main user settings.

Any help would be appreciated.

Som

2

Another note here that adds to the confusion for me: the “test connection” works for this connection. I can supply the username/pw and I get a successful test.

But whenever I try and actually log into my application, I get a “wrong username or password” response.

Som

3

So – looks like Auth0 doesn’t support multiple database connections using the Universal login page. It appears this is possible using the embedded lock app, just not the Universal page.

Seems pretty misleading to support multiple database connections and not make it in-your-face obvious that login attempts will not cycle through databases looking for the first match.

Som

4

Supporting multiple database connections without having the user preselecting the connection, or without preselecting it by some logic is hard to do. It would also cause a few issues.

Let’s assume you have multiple database connections that allow both email addresses and usernames. Remember, usernames as well as email addresses don’t have to be unique across multiple databases, so they can exist both in each.

login attempts will not cycle through databases looking for the first match.

Looking for the first match wouldn’t really work well. Let’s consider these two users and their passwords in two DB connections. Both myuser users being actually two different people.

DB Connection 1:
Name: Mr . A, Username: myuser, Password: secret

DB Connection 2:
Name: Mr. B, Username: myuser, Password: love

If Mr. A tries to login into DB1, but enters (from his point of view) wrong password, such as “love”, the system should show him that the login failed, but would then instead incorrectly log him in as a totally different user (that just happens to have the same username like him, but in a different connection).

Also, if both Mr. A and Mr. B had the same username, it would mean that Mr. B would never be able to log into his account, because Mr. A’s account would always get the priority.

Though it might not be very probable that two different users choose the same username and password, it’s still possible.

Another issue is with signup: if the user/system doesn’t select the DB connection in advance, the system wouldn’t know if a username can be used for signup or not (if it’s already used in one DB connection but not in the other).

5

Thank you for the response – I think those limitations make sense. I’d have a couple pieces of feedback:

  1. I’m not sure if it’s a common enough use case, but if usernames and signups aren’t needed (they aren’t for me), the rollover logic wouldn’t fall into the traps you described. You should be able to get away with email/pw rollover, as far as I can tell…?

  2. It’s probably worth providing some visual indication to users that create multiple DB connections that are associated with the same app that the rollover capabilities aren’t there. Like, “Hey, we noticed this App is associated to more than 1 DB connection. Please note that this means you will need to do x/y/z things to ensure the login routes to the appropriate DB.”

What I’m still not clear on is – does the Universal login even support multiple DBs? If it’s something that needs to be triggered by the caller, it would be helpful to not have a default functionality that only uses the first DB and ignores the rest and, instead, forces the implementor to designate the connection to use for a particular login attempt. This way, during development, it’ll be clear that multiple databases aren’t supported.

Thanks again for the feedback!

Som

6

Hi @somnaderi,

  1. Understand, if only email address is used (and verified!), then we can assume it’s the same actual person. However, if the user is in two databases and uses the same password in two, always his first entry will be chosen. On the other hand, then you would most like have the account linking/merging in place anyway. So, understand your point here, but this roll over isn’t supported in Lock.
    The question in which DB to put newly signed up users would still remain open.

  2. Agreed, a warning in the dashboard would make sense.

It’s not possible to use two database connections with Lock at the same time, at least not in a useful way. If multiple DB connections are enabled, then it’s usually in scenarios where upfront the connection is already chosen based on a certain logic (provided by the developer/admin), and set via

allowedConnections: see docs
or
defaultDatabaseConnection: see docs

7

@somnaderi I forgot to mention this option of using a ConnectionResolver:

This only works though if you have a way to distinguish which of your SaaS customer it is, i.e. based on email address domain.

(Note: it requires Lock and therefore is only available in the Classic login page, not the New Universal Login Page / ULP.)