Multiple db connections for a single app

Hi,

I have a question regarding a single-page-app and 2 db connections. Here is the scenario:

  • I have one db-connection for standard “email” logins and another db-connection for “username” logins. Both are used for separate groups of people.

  • Creating the db connections and testing them within the auth0 dashboard worked fine.

  • Upon sign-up, I want to be able to:
    a) assign a specific role
    b) select which db-connection to use for the registration

  • Upon sign-in, I want to be able to:
    a) select which db-connection to use for signing in

  • Ideally I would continue to use the central auth0 login. Each user-group has their own login-button in the lSPA.

I have read about using rules, hooks and connectionResolvers to solve this but I am still unsure what to use for my use-case. Also, do I understand it correctly that my use-case is only possible with the classic universal login?

Thanks and best regards,
Michael

Hi @mdelabb

What is the reason you require two separate connections?

Is there overlap in the 2 user bases? That doesn’t make much sense to me.

Could you store both sets of users in the same connection? (You can do tricks like use a random guid for user ID if some users do not want a user ID).

You can do this with custom code in the ULP to set the connection parameter, though that is some work.

John

Hi John,

Thanks very much for your response.

No, there will be no overlap in user bases. In fact, I will be able to distinguish between them pretty well according to their email addresses.

Basically the two user groups have an adult/kids relationship. In other words, the adult has to create an initial account and then he/she can create the kid’s account via our backend API, that will in turn register the kid-user with auth0. Kids do not all have an email address so we do not want to require that. In order for it to work with auth0 we will just give the kid one of our own email addresses as it is a mandatory field. The kids’s email address will otherwise be used for nothing though.

The kid can choose any cool username it wants.

Yes, we can have both user-groups in the same connection, anything that works. Theoretically we could just enable username for both and then register the adults with an email address as username. I did also have different password-strengths configured for the two but we can leave that out if necessary.

Thinking about it, there is one other setting that we will need to separate between the two. Adults should see a sign-up link but not the kids as the adults should take care of that via our API.

To be honest, I do not mind at all which solution we will use in the end. We just need something that works. A simple solution would be a nice bonus of course but I have the feeling that this will be slightly more complicated.

Michael

Hi @mdelabb

Are the adults and kids using separate apps/login pages? It sounds like they are.

If so, then you CAN use two connections, you just specify the connection in the app: the adult app will use the adult connection and the child app will use the child connection.

Otherwise I’d recommend using a single connection, and leveraging rules and metadata to achieve your ends.

John

Hi John,

The app is the same but there is a separate button for each type of login. The buttons are both on the same page in the header.

Otherwise I’d recommend using a single connection, and leveraging rules and metadata to achieve your ends

Ok, I suppose the only option would then be to have both groups login via a username. Would I be able to remove the sign-up link for only one of the two if I did that?

Michael
.

Hi @john.gateley,

I would just like to get back to this solution as we need to be able to leave out the sign-up link for one of the groups:

I have just had a look at the documentation and am not 100% sure which option you mean. Are you referring to:

  1. Auth0.js v9 Reference and Auth0.js v9 Reference OR
  2. Lock Configuration Options OR
  3. Something completely different?

Would your suggested solution work with the new universal login, the classical login or would we need to do the login and registration in our app. I don’t mind either as long as we have a solution.

Best regards,
Michael

Hi @mdelabb

Even though it is one app, create two apps(clients) in the dashboard.
For app Adult, only enable the adult connection.
For app Child, only enable the child connection.
Then ULP should just do the right thing for you (whether classic or new).

Your buttons will need to start the ULP process with the right client.

John

1 Like

Hi @john.gateley

Thanks very much for you time! That sound like a viable solution - I’ll give it a try. I’ll just have to find out how to separate my global Auth0Provider (as provided in the Auth0 React-SDK examples) for the 2 buttons (both located next to each other in the header):

ReactDOM.render(
  <React.StrictMode>
    <Auth0Provider
      domain="example-dev.com"
      clientId="12345"
      redirectUri={window.location.origin}
    >
      <App />
    </Auth0Provider>
  </React.StrictMode>,
  document.getElementById("root")
);

Currently both my buttons simply both call:

    <button onClick={() => loginWithRedirect()}>Adult Sign In</button>
    <button onClick={() => loginWithRedirect()}>Kid Sign In</button>

Not sure how I will do that yet for the reasons mentioned above but I’ll give it a go.

Best regards,
Michael

Hi,

I think I have got it working as expected now. Thanks for the tip. I’ll explain briefly what I did in case someone else finds it useful.

  • 2 apps were created. One called Kid-App and one called Adult-App.
  • 2 db connections were created. Again, one for the kids and one for the adults.
  • Both apps were configured to only use their own database.
  • Both db connections were configured to only allow one app to use them (kid->kid, adult->adult).
  • The options “Disable Sign Ups” and “Requires Username” were set for the kids db connection.

And voilá, I had to two different auth0 sign ins in my React SPA, one per username and without sign up for the kids and one normal adult sign in.

The <AuthProvider /> was then moved from index.tsx to the header.tsx where the 2 login buttons are (one for kid and one for adult):

Header.tsx

import React from "react";
import { Auth0Provider } from "@auth0/auth0-react";
import "./Header.css";
import LoginButton from "./LoginButton";
import LogoutButton from "./LogoutButton";

function Header() {
  return (
    <header>
      <nav>
        {/* Adult Login */}
        <Auth0Provider
          domain="example-app-dev.auth0.com"
          clientId="1234512345"
          redirectUri="http://localhost:3000/adults/"
        >
          <LoginButton label="Adult Sign In" />
          <LogoutButton />
        </Auth0Provider>
        {/* Kid Login */}
        <Auth0Provider
          domain="example-app-dev.auth0.com"
          clientId="9876598765"
          redirectUri="http://localhost:3000/kids/"
        >
          <LoginButton label="Kid Sign In" />
          <LogoutButton />
        </Auth0Provider>
      </nav>
    </header>
  );
}

export default Header;

LoginButton.tsx

import React from "react";
import { useAuth0 } from "@auth0/auth0-react";

const LoginButton = (props: { label: String }) => {
  const { loginWithRedirect } = useAuth0();

  return <button onClick={() => loginWithRedirect()}>{props.label}</button>;
};

export default LoginButton;
  • Both buttons provide their own redirectUri, which has to be configured for each app in the “Allowed Callback URLs” field.
  • Notice how both <AuthProviders/> have a different clientId. One for the kid-app and one for the adult-app.

The setup is actually a lot simpler than I anticipated. It helps of course to have a better understanding of how auth0 works.

Also, I had not thought of putting both apps in separate react-projects before, which made it more complicated and makes little sense anyway.

I now have 3 apps:

  1. Homepage with login and redirect to kid or adult app.
  2. Kid app.
  3. Adult app.

Thanks again!

Best regards,
Michael

1 Like

Teamwork make the dreamwork! We’re here for you!

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.