Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /
Authenticate & Manage Users

Definir metadatos del usuario personalizados

Puedes asociar metadatos personalizados con cada usuario de tu aplicación. Por ejemplo, puedes almacenar el lenguaje preferido de un usuario, su fecha de nacimiento, o cualquier otra información que desees asociar con el usuario.

Puede obtener los metadatos de un usuario de dos fuentes:

  • A collection in MongoDB Atlas that stores custom user data. You can associate each user with a document in the collection by their user ID. You can store arbitrary data in each document.

  • Un proveedor de autenticación. Si el proveedor utiliza tokens web JSON, como Google, Facebook o un proveedor personalizado, puede definir campos de metadatos en la configuración del proveedor que asocien los datos del JWT del usuario con su cuenta.

You can store arbitrary data about your application users in a MongoDB collection. Your App maps each user to a document in the collection by querying a specific field for the user's ID. When a user authenticates, your App looks up the user's data and includes it in their access token.

Considere un usuario con el ID "63ed2dbe5960df2af7fd216e"Si su recopilación de datos de usuario personalizada se configuró para almacenar el ID del usuario en el campo userId, el usuario se asignaría al siguiente documento:

{
"_id": "63ed2e4fb7f367c92578e526",
"user_id": "63ed2dbe5960df2af7fd216e",
"preferences": {
"preferDarkMode": true
},
"dateOfBirth": "1989-03-11T00:00:00.000Z"
}

Al utilizar datos de usuario personalizados, tenga en cuenta lo siguiente:

  • Almacenar un documentopor usuario: Los documentos que contienen datos de usuario deben incluir el ID del usuario en un campo específico. Si varios documentos especifican el mismo ID de usuario, App Services solo expone los datos del documento que se insertó primero.

  • Mantenga los datos de usuario personalizados pequeños: El documento de usuario personalizado completo se incluye en su token de acceso. En general, intente que los documentos de datos de usuario personalizados sean pequeños (por ejemplo, menos de 16 KB). Otros servicios podrían limitar el tamaño del encabezado HTTP, lo que significa que objetos de datos de usuario personalizados más grandes pueden causar problemas de integración.

  • Custom Data May Be Stale: A user's custom data is sourced from a MongoDB collection but is stored in and read from a user's authentication access token. If a user has a valid access token when the underlying document changes, their custom data in that session does not update until they refresh their access token or re-authenticate.

Usted es responsable de gestionar los documentos en la colección de datos de usuario personalizada. Según su caso de uso, puede:

  • Cree automáticamente un documento para cada usuario cuando se registre en su aplicación mediante un Función de creación de usuarios. Esta función se ejecuta antes de que se le asigne un token de acceso al usuario, por lo que los datos que agregue estarán en el token de acceso en su primer inicio de sesión.

  • Utilice un disparador de autenticación para actualizar los datos personalizados de un usuario al registrarse o iniciar sesión, y para eliminarlos si se elimina su cuenta. Los disparadores se ejecutan de forma asíncrona y pueden finalizar después de crear el token de acceso del usuario.

  • Usa un disparador programado para actualizar o borrar periódicamente datos de usuario personalizados.

  • Cree, actualice y elimine manualmente documentos en la colección utilizando operaciones CRUD estándar desde una función, un SDK de dispositivo Atlas, un controlador MongoDB o MongoDB Compass.

Si los datos de usuario personalizados de su aplicación incluyen información personal o privada, debe restringir el acceso a la recopilación de datos de usuario personalizados. Considere usar uno de los siguientes modelos de permisos para restringir el acceso de lectura y escritura solo a usuarios con privilegios:

  • Un usuario puede leer o guardar su propio documento de datos de usuario personalizados. Denegar el acceso de lectura y guardado a todos los demás documentos.

    Ejemplo

    The following collection configuration has one role that grants a user read and write access to a document if and only if their ID is contained in the document's user_id field.

    Una configuración de colección de datos de usuario personalizada
    {
    "database": "<Database Name>",
    "collection": "<Collection Name>",
    "roles": [
    {
    "name": "ThisUser",
    "apply_when": { "user_id": "%%user.id%%" },
    "insert": false,
    "read": true,
    "write": true,
    "search": false,
    "delete": false
    }
    ],
    "filters": []
    }
  • Ningún usuario puede leer ni escribir documentos de datos de usuario personalizados. En su lugar, utilice una función del sistema para gestionar los datos de usuario personalizados en nombre de los usuarios.

Puede definir una función que se ejecute cada vez que un nuevo usuario se registre correctamente, pero antes de que se cree su nueva cuenta. Si la función genera un error o presenta algún otro error, la creación de la cuenta falla. Esto le permite garantizar que los usuarios siempre tengan datos personalizados asociados una vez creados.

La función recibe un objeto de metadatos del usuario como su único argumento. Puedes usar esto para crear un nuevo documento de datos de usuario personalizados para el usuario.

exports = async function onUserCreation(user) {
const customUserDataCollection = context.services
.get("mongodb-atlas")
.db("myapp")
.collection("users");
try {
await customUserDataCollection.insertOne({
// Save the user's account ID to your configured user_id_field
user_account_id: user.id,
// Store any other user data you want
favorite_color: "blue",
});
} catch (e) {
console.error(`Failed to create custom user data document for user:${user.id}`);
throw e
}
}

Tip

Una vez que hayas configurado una función de creación de usuarios, aplicación Services te impide eliminar la función. Si desea borrar la función, primero cambie su configuración personalizada de datos de usuario para usar una función de creación de usuario diferente.

Puede configurar y habilitar datos de usuario personalizados en la interfaz de usuario de administración de App Services.

1

Haga clic App Users En el menú de navegación izquierdo, seleccione la pestaña User Settings y busque la sección Custom User Data.

2

Haga clic en el interruptor Enable Custom User Data para establecerlo en On.

El botón de alternancia para activar datos de usuario personalizados en la Interfaz de usuario Realm, activado.
haga clic para ampliar
3

Debe almacenar los datos personalizados de los usuarios de su aplicación en una única colección de un clúster de MongoDB Atlas vinculado. Para configurar su aplicación para que lea los datos de usuario de esta colección, debe especificar los siguientes valores:

  • Cluster Name:El nombre de un clúster MongoDB vinculado que contiene la colección de datos de usuario personalizada.

  • Database Name:El nombre de la base de datos MongoDB que contiene la colección de datos de usuario personalizados.

  • Collection Name:El nombre de la colección MongoDB que contiene datos de usuario personalizados.

Cuadros de entrada para el campo de colección e identificación de usuario en la interfaz de usuario de App Services.
haga clic para ampliar
4

Cada documento en la colección de datos de usuario personalizada tiene un campo que lo asigna a un usuario específico de la aplicación. El campo debe ser del tipo ObjectID o de un tipo string que represente ese ObjectID. Este campo debe estar presente en cada documento que se asocia a un usuario.

Especifique el nombre del campo que contiene el ID de cada usuario en la entrada User ID Field.

Nota

Si dos documentos contienen el mismo ID de usuario, uno almacenado como una cadena y el otro como un ObjectID, App Services asigna el documento con el tipo de cadena al usuario.

5

If you want to use a user creation Function, define it in the inline editor or reference an existing function by name.

6

Una vez que hayas configurado la colección de datos de usuario personalizada, puedes hacer que los datos de usuario personalizados estén disponibles para las aplicaciones cliente al implementar tu aplicación. Para implementar una aplicación borrador desde la Interfaz de usuario Realm:

  1. Haga clic en Deploy en el menú de navegación de la izquierda.

  2. Busque el borrador en la tabla del historial de implementación y luego haga clic en Review & Deploy Changes.

  3. Revise la diferencia de cambios y luego haga clic en Deploy.

Una vez que la aplicación se implemente con éxito, App Services comienza a asociar datos personalizados con los usuarios. Cuando un usuario inicia sesión, App Services consulta automáticamente la colección de datos de usuario personalizada por un documento donde el User ID Field especificado contiene el ID del usuario. Si un documento coincide, aplicación Services expone los datos del documento en el campo custom_data del objeto de usuario.

1

To define custom user data with appservices, you need a local copy of your application's configuration files.

Para extraer una copia local de la última versión de su aplicación, ejecute lo siguiente:

appservices pull --remote="<Your App ID>"

Tip

También puedes descargar una copia de los archivos de configuración de tu aplicación desde la pantalla Deploy > Export App en la Interfaz de usuario Realm.

2

Debe almacenar los datos personalizados de los usuarios de su aplicación en una única colección de un clúster Atlas vinculado. Cada documento de la colección debe incluir un campo específico que contenga el ID del usuario de App Services que describe.

Para configurar su aplicación para que lea datos de usuario de esta colección, defina un documento de configuración de datos de usuario personalizado /auth/custom_user_data.jsonen:

/auth/custom_user_data.json
{
"enabled": <Boolean>,
"mongo_service_name": "<MongoDB Data Source Name>",
"database_name": "<Database Name>",
"collection_name": "<Collection Name>",
"user_id_field": "<User ID Field Name>",
"on_user_creation_function_name": "<Function Name>"
}
3

Una vez configurados los datos de usuario personalizados, puedes enviar la configuración actualizada a tu aplicación remota. La CLI de App Services implementa la actualización inmediatamente al enviarla.

appservices push --remote="<Your App ID>"

Para obtener ejemplos de código que demuestran cómo acceder y actualizar datos de usuario personalizados desde la aplicación cliente, consulte la documentación de los SDK de dispositivos Atlas:

Los permisos se actualizarán automáticamente al modificar el documento de datos de usuario personalizado. La sesión se cerrará y se actualizará automáticamente.

Para que los permisos de usuario se actualicen automáticamente, los documentos de datos de usuario personalizados deben almacenarse en una colección normal y no en una vista ni en una colección de series de tiempo.

For permissions to refresh automatically, don't delete a custom user data document. Rather, unset all the non-ID fields in the document.

Ejemplo

Consider the following document where the user is assigned read and write permissions:

Documento de datos de usuario personalizado
{
"_id": "63ed2erealobjectid78e526",
"user_id": "63ed2dbe5960df2af7fd216e",
"canRead": true,
"canWrite": true,
}

Los campos canRead y canWrite pueden ayudar a determinar los roles de la colección de este documento. Por ejemplo, el campo canRead se utiliza para determinar la elegibilidad para el siguiente readAllRole en la expresión apply_when:

Documento de datos de usuario personalizado
{
"name": "readAllRole"
"apply_when": {"%%user.custom_data.canRead": true},
...
}

Supongamos que desea eliminar el documento de un usuario porque ha estado inactivo durante un período prolongado. Primero, debe eliminar correctamente los permisos del empleado desactivando los campos que no sean de ID. El documento se vería así:

Documento de datos de usuario personalizados actualizado correctamente
{
"_id": "63ed2erealobjectid78e526",
"user_id": "63ed2dbe5960df2af7fd216e"
}

Desactivar el campo que no sea el ID permite que los Servicios de aplicaciones actualicen automáticamente los permisos del usuario según los roles. Ya puedes borrar de forma segura el documento si es necesario.

Atlas App Services puede leer metadatos de usuario de proveedores de autenticación. Luego, App Services expone los datos de cada usuario en un campo de su objeto de usuario. Por ejemplo, podría querer acceder al nombre, correo electrónico, fecha de nacimiento o género de un usuario.

Puede configurar App Services para solicitar metadatos con el token de acceso cuando los usuarios inician sesión. Puedes acceder a esos datos desde el objeto del usuario que ha iniciado sesión con un SDK cliente.

Puedes definir los metadatos que se solicitarán al configurar los proveedores de autenticación. Especifica los campos opcionales de metadatos a los que deseas acceder a través de la cuenta del usuario. Estos campos de metadatos varían según el proveedor.

Proveedor
Campos de metadatos

Facebook

  • name

  • first_name

  • last_name

  • picture

  • gender

  • birthday

  • min_age

  • max_age

  • email

Google

  • name

  • first_name

  • last_name

  • picture

  • email

JWT personalizado

Any field in the JWT as specified by the Custom JWT provider's metadata fields configuration.

Importante

Evite los metadatos obsoletos del proveedor de autenticación

Si los metadatos de un usuario se actualizan después de emitir el token de acceso, las solicitudes que utilicen el token de acceso creado previamente no tendrán los metadatos recién actualizados. Sus metadatos de usuario se actualizarán al actualizar el token de acceso o volver a autenticarse.

Nota

Metadatos del proveedor de seguridad y autenticación

Los metadatos del proveedor de autenticación pueden ser definidos externamente por clientes y proveedores de autenticación externos, y deben considerarse con precaución. No se debe confiar únicamente en los metadatos del proveedor de autenticación para tomar decisiones relacionadas con la seguridad, como usar estos metadatos en expresiones de reglas para permisos de acceso a datos.

1

Puedes configurar y habilitar los metadatos de usuario en la interfaz de usuario de App Services. Para acceder a la página de configuración:

  • Haga clic en Authentication en el menú de navegación de la izquierda.

  • Selecciona la pestaña Authentication Providers.

  • Presione el botón EDIT para el proveedor cuyos metadatos desea configurar.

2

Google o Facebook

Selecciona las casillas junto a los campos de metadatos que deseas habilitar.

Las casillas de verificación para habilitar los campos de metadatos del usuario en la interfaz de usuario de App Services
haga clic para ampliar

Autenticación JWT personalizada

Puedes especificar los campos de metadatos que admite tu proveedor de identidad. Después de presionar el botón Add Field, define:

  • El camino

  • El nombre del campo

  • Si el campo es opcional u obligatorio

Para obtener más detalles, consulte: Campos de metadatos JWT.

Add metadata required/optional, path, and name in the App Services UI
haga clic para ampliar

Después de configurar los metadatos a los que desea acceder, presione el botón Save Draft.

3

Después de actualizar la configuración de metadatos, debe implementar su aplicación. Para implementar un borrador de aplicación desde la interfaz de usuario de App Services:

  1. Haga clic en Deploy en el menú de navegación de la izquierda.

  2. Busque el borrador en la tabla del historial de implementación y luego haga clic en Review & Deploy Changes.

  3. Revise la diferencia de cambios y luego haga clic en Deploy.

Una vez implementada correctamente la aplicación, App Services comienza a asociar metadatos con los usuarios. Cuando un usuario inicia sesión, App Services le solicita permiso para acceder a los metadatos solicitados. Si el usuario lo aprueba, App Services expone los datos en su objeto de usuario.

1

To update your app with appservices, you need a local copy of its configuration files.

Para extraer una copia local de la última versión de su aplicación, ejecute lo siguiente:

appservices pull --remote="<Your App ID>"

Tip

You can also download a copy of your application's configuration files from the App Services UI. Go to the Deploy > Export App screen from the App Dashboard.

2

You can find authentication provider metadata_fields for your app in /auth/providers.json. Update this array to request user metadata from the authentication provider.

Google o Facebook

Esta matriz se parece a:

/auth/proveedores.json
{ ...other config details...
"metadata_fields": [
{
"required": false,
"name": "name"
},
{
"required": false,
"name": "gender"
}
]
}

Autenticación JWT personalizada

La arreglo metadata_fields tiene una propiedad adicional, field_name. En la autenticación JWT personalizada, name representa la ruta al campo. El field_name representa el nombre del campo.

/auth/proveedores.json
{ ...other config details...
"metadata_fields": [
{
"required": true,
"name": "user.name",
"field_name": "name"
},
{
"required": false,
"name": "user.favoriteColor",
"field_name": "favoriteColor"
}
]
}
3

Una vez configurados los datos de usuario personalizados, puedes enviar la configuración actualizada a tu aplicación remota. La CLI de App Services implementa la actualización inmediatamente al enviarla.

appservices push --remote="<Your App ID>"
1

Call the admin user authentication endpoint with your MongoDB Atlas API key pair:

curl -X POST \
https://services.cloud.mongodb.com/api/admin/v3.0/auth/providers/mongodb-cloud/login \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-d '{
"username": "<Public API Key>",
"apiKey": "<Private API Key>"
}'

If authentication succeeds, the response body contains a JSON object with an access_token value:

{
"access_token": "<access_token>",
"refresh_token": "<refresh_token>",
"user_id": "<user_id>",
"device_id": "<device_id>"
}

El access_token concede acceso a la API de Administración de App Services. Debe incluirlo como un token Bearer en el encabezado Authorization para todas las solicitudes a la API de administración.

2

Envíe una solicitud al punto final "Actualizar un proveedor de autenticación". En el cuerpo de la solicitud, defina metadata_fields para el proveedor.

Asegúrate de incluir tu access_token de la API de administrador, el groupId del Proyecto de Atlas que contiene tu aplicación, la cadena hexadecimal interna appId de tu aplicación y el valor de _id del proveedor de autenticación:

curl --request PATCH 'https://services.cloud.mongodb.com/api/admin/v3.0/groups/{groupId}/apps/{appId}/auth_providers/{providerId}' \
--header 'Authorization: Bearer <access_token>' \
--header 'Content-Type: application/json' \
--data '{
"_id": "<Provider ID>",
"name": "oauth2-facebook",
"type": "oauth2-facebook",
"redirect_uris": ["https://example.com/"],
"config": {
"clientId": "<Facebook Client ID>"
},
"secret_config": {
"clientSecret": "<Facebook Client Secret Name>"
},
"metadata_fields": [
{ "required": false, "name": "name" },
{ "required": true, "name": "first_name" },
{ "required": true, "name": "last_name" },
{ "required": false, "name": "picture" },
{ "required": false, "name": "gender" },
{ "required": false, "name": "birthday" },
{ "required": false, "name": "min_age" },
{ "required": false, "name": "max_age" },
{ "required": false, "name": "email" }
],
"disabled": false
}'
curl --request PATCH 'https://services.cloud.mongodb.com/api/admin/v3.0/groups/{groupId}/apps/{appId}/auth_providers/{providerId}' \
--header 'Authorization: Bearer <access_token>' \
--header 'Content-Type: application/json' \
--data '{
"_id": "<Provider ID>",
"name": "oauth2-google",
"type": "oauth2-google",
"redirect_uris": ["https://example.com/"],
"config": {
"clientId": "<Google Client ID>"
},
"secret_config": {
"clientSecret": "<Google Client Secret Name>"
},
"metadata_fields": [
{ "required": false, "name": "name" },
{ "required": true, "name": "first_name" },
{ "required": true, "name": "last_name" },
{ "required": false, "name": "picture" },
{ "required": false, "name": "gender" },
{ "required": false, "name": "birthday" },
{ "required": false, "name": "min_age" },
{ "required": false, "name": "max_age" },
{ "required": false, "name": "email" }
],
"disabled": false
}'
curl --request PATCH 'https://services.cloud.mongodb.com/api/admin/v3.0/groups/{groupId}/apps/{appId}/auth_providers/{providerId}' \
--header 'Authorization: Bearer <access_token>' \
--header 'Content-Type: application/json' \
--data '{
"_id": "<Provider ID>",
"name": "custom-token",
"type": "custom-token",
"metadata_fields": [
{
"required": true,
"name": "jwt.field.path",
"field_name": "metadataFieldName"
}
],
"config": {
"audience": [],
"requireAnyAudience": false,
"signingAlgorithm": "HS256",
"useJWKURI": false
},
"secret_config": {
"signingKeys": [
"<JWT Signing Key>"
]
},
"disabled": true
}'

Si configura correctamente los campos de metadatos del proveedor, App Services devuelve una respuesta 204.

Nota

Tips for Users with Multiple Linked Authentication Providers

  • Para garantizar los metadatos más actualizados, los usuarios deben volver a autenticarse después de cambiar de proveedor de autenticación. De lo contrario, los metadatos podrían quedar obsoletos en la tabla Users de la página App Users de la interfaz de usuario y en las solicitudes que utilicen proveedores de autenticación.

  • Si un usuario cambia de proveedor de autenticación, la propagación de los metadatos puede tardar hasta 30 minutos. Se garantiza que la solicitud siempre contenga los metadatos más actualizados asociados al proveedor de autenticación utilizado.

For code examples that demonstrate how to access user metadata data from the client application, see the documentation for the Atlas Device SDKs:

Volver

Crea un usuario