Skip to content

Commit bc02787

Browse files
authored
Merge pull request auth0#6707 from auth0/remove-mongo-scripts-checklist
Removed Mongo
2 parents 822245e + 4c98bd9 commit bc02787

File tree

1 file changed

+6
-4
lines changed
  • articles/connections/database/custom-db/templates

1 file changed

+6
-4
lines changed

articles/connections/database/custom-db/templates/index.md

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -25,15 +25,17 @@ While Auth0 has populated default templates in the Dashboard script editor, you
2525
Use the following checklist to make sure your scripts achieve the results you intend:
2626

2727
1. **Set a `user_id` on the returned user profile that is consistent for the same user every time.**
28-
In the migration scenario, this is important because if you try to set a random `user_id` for each login and you call `forgot password` twice, and then try to follow the second link, the user is unable to migrate. One of the user stores in Mongo gets confused if you have the same email address but more than one ID if you do the forgot password twice. The result is that every time a user logs in, they will get a new user created in the user list.
29-
30-
In the non-migration scenario, this is important because you can end up with duplicate users in the Auth0 database.
28+
In the migration scenario, this is important because if you set a random `user_id` in the `get_user` script, then call `forgot password` and change the password, the user will get duplicated every time they log in. In the non-migration scenario, if you set a random `user_id` you can end up with duplicate users for every login.
3129

3230
2. **If using a `username`, ensure that you aren't returning the same email address for two different users in the `get_user` or `login` script.**
3331
Auth0 will produce an error if you do this, but it is better to catch it in the script itself.
3432

3533
3. **If setting `app_metadata`, call it `metadata` in the script.**
36-
In Mongo, `app_metadata` is called `metadata`. Everywhere that `metadata` is used, it is translated to `app_metadata` except in custom database scripts. If you don't use `metadata` in the script, you will get an error where `app_metadata` will work but if you use the API to merge `app_metadata` with a user, it will appear as if all of your `app_metadata` was lost. This happens because the script creates the new `metadata` field and won't return the original `app_metadata`.
34+
To support backwards compatibility, `app_metadata` is called `metadata` in custom DB scripts. If you don't use `metadata` in the script, you will get an error where `app_metadata` will work but if you use the API to merge `app_metadata` with a user, it will appear as if all of your metadata was lost.
35+
36+
::: note
37+
`user_metadata` is not affected by this and can simply be called `user_metadata`.
38+
:::
3739

3840
4. **If using Auth0 to do machine-to-machine to the legacy database, restrict access to that audience with a rule.**
3941
As with any API that you create, if you create it solely for client credentials, then you will want to restrict access to the API in a rule. By default, Auth0 gives you a token for any API if you authenticate successfully and include the audience. Someone could intercept the redirect to authorize and add the audience to your legacy database API. If you don’t block this in a rule, they will get an access token.

0 commit comments

Comments
 (0)