You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/connections/database/custom-db/templates/index.md
+6-4Lines changed: 6 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -25,15 +25,17 @@ While Auth0 has populated default templates in the Dashboard script editor, you
25
25
Use the following checklist to make sure your scripts achieve the results you intend:
26
26
27
27
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.
31
29
32
30
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.**
33
31
Auth0 will produce an error if you do this, but it is better to catch it in the script itself.
34
32
35
33
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
+
:::
37
39
38
40
4.**If using Auth0 to do machine-to-machine to the legacy database, restrict access to that audience with a rule.**
39
41
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