Different Authentication Profiles per Environment


Just a question when using multiple environments, we’ve got a master → staging environment set up, and were looking to use two authentication profiles between the two, however branches by default copy their master branches authentication profiles, and adding/removing any on the new branch means those same changes are then made to the master branch when committing. I.e., we have two Auth0 tenants, one for master and one for staging, however we can’t seem to add/remove the tenants without them being copied into the commit data.

What would be the right way to set up a separate authentication profile per environment?


1 Like

Hello @nce.softdev !
You have two options:

  1. Leave all the auth profiles in each environment. They have different IDs, and environments have different edpoints (https://api.8base.com/<workspaceId>_<envName>) so there would be no conflict.
  2. Create one auth profile, write a script with auth profile update mutation which will change the domain/other credentials and run it every time you make a clone of environment. In this case you’ll have to manually delete migration for updating auth profile before committing generated migrations though.
1 Like

Could you explain the first point a bit more please? They are still associated with the same environments, so someone could authenticate with our staging profile and use an idToken to make requests against our master environment?

Isn’t there a way to do this without manually editing the auto-generated migration files? I would of thought a different auth profile per environment would have been one of the most typical use cases of using multiple authentication profiles?


Yeah, that’s actually might happen if the user is signed up with the same role and email in both environments.

No, unfortunately, for now…

I’ve advised with our dev team - someone uses a script for dealing with
unnecessary migrations, someone doesn’t care about auth profiles management between the environments, cause there is not much risk of messing up master data.

We will think about improving this, though!

1 Like