Passer au contenu principal
Un type de connexion de base de données personnalisée vous permet de configurer des scripts d’action, qui contiennent du code personnalisé utilisé par Auth0 pour s’interfacer avec votre magasin d’identité hérité. Les scripts d’action sont des fonctions JavaScript nommées qui acceptent un ensemble prédéfini de paramètres.

​
Conteneurs Webtask

Les scripts d’action s’exécutent dans un conteneur Webtask distinct, avec une limite d’exécution d’environ 20 secondes. Une fois les fonctions exécutées, le conteneur est recyclé. Lorsqu’un conteneur est recyclé, il met fin aux opérations en attente du script d’action. Cela peut entraîner le retour d’une erreur et la réinitialisation possible de l’objet global. Pour en savoir plus sur l’objet global, consultez Pratiques exemplaires pour l’environnement des scripts d’action de base de données personnalisée.

​
Fonctionnalités asynchrones

Les fonctionnalités asynchrones de JavaScript, y compris les objets Promise et les fonctions async, sont prises en charge dans les scripts d’action. Vous pouvez utiliser les fonctionnalités asynchrones pour exécuter des opérations non bloquantes dans un script d’action, mais assurez-vous que ces opérations ne dépassent pas la limite d’exécution du conteneur Webtask. Lorsque le conteneur Webtask est recyclé, il met fin à toute opération en attente, ce qui peut entraîner un comportement inattendu ou une erreur. Si vous effectuez un appel à un service externe ou à une API dans votre script d’action, définissez un délai d’expiration raisonnable pour la fonction, puis renvoyez une erreur si le service externe ou l’API est inaccessible.

​
Exemples

Auth0 prend en charge l’utilisation d’objets Promise et de fonctions async dans les scripts d’action.

​
Objet Promise

Cet exemple utilise la méthode JavaScript intégrée fetch, qui récupère une ressource depuis le réseau, puis renvoie un objet Promise. Il est présenté à l’aide d’un chaînage de promesses. 
function login(userNameOrEmail, password, callback) {
	const hashedPassword = hash(password);
	const apiEndpoint = 'https://example.com/api/authenticate';
	const options = {
		method: 'POST',
		body: {
			email: userNameOrEmail,
			password: hashedPassword
		}
	};

	fetch(apiEndpoint, options) 
		.then((response) => {
			if (!response.ok) {
				return callback(new Error(`HTTP error! Status: ${response.status}`));
			}

			return response.json();
		})
		.then((response) => {
			if (response.err) {
				return callback(new Error(`Error authenticating user: ${err}`));
			}

			let profile = {
				email: response.profileData.email,
				username: response.profileData.username
			};

			return callback(null, profile);
		})
		.catch((err) => {
			return callback(new Error(`An error occurred: ${err}`));
		});
  }

​
Fonction asynchrone

Cet exemple utilise la méthode JavaScript intégrée fetch, qui récupère une ressource sur le réseau et renvoie un objet Promise. Il est rédigé à l’aide de fonctions asynchrones. 
async function login(userNameOrEmail, password, callback) {
	const hashedPassword = hash(password);
	const apiEndpoint = 'https://example.com/api/authenticate';
	const options = {
		method: 'POST',
		body: {
			email: userNameOrEmail,
			password: hashedPassword
		}
	};

	const response = await fetch(apiEndpoint, options);

	if (!response.ok) {
		return callback(new Error(`HTTP error! Status: ${response.status}`));
	}

	const result = response.json();

	if (result.err) {
		return callback(new Error(`Error authenticating user: ${err}`));
	}

	let profile = {
		email: response.profileData.email,
		username: response.profileData.username
	};

	return callback(null, profile);
}

​
Fonction de rappel

La fonction callback indique que l’exécution du script d’action est terminée et doit être appelée exactement une fois. Un script d’action doit se terminer immédiatement après l’appel à la fonction callback, de préférence en utilisant explicitement l’instruction return.
Si la fonction callback est appelée plus d’une fois, cela peut entraîner des résultats inattendus ou des erreurs.Si la fonction callback n’est jamais appelée, l’exécution du script d’action se bloquera et une erreur sera renvoyée lorsque le conteneur Webtask sera recyclé.

​
Traitement asynchrone

Si un script d’action utilise un traitement asynchrone, la fonction callback doit être appelée seulement une fois toutes les opérations asynchrones terminées.

​
Paramètres

Si la fonction callback est appelée sans aucun paramètre, elle s’exécute comme si un paramètre null avait été fourni.

​
Taille

La taille totale de l’implémentation de tout script d’action ne doit pas dépasser 100 kB. Cette limite n’inclut pas les modules npm importés. Pour en savoir plus sur les modules npm, consultez Pratiques exemplaires pour l’environnement des scripts Action de base de données personnalisée. Plus un script est volumineux, plus le processus d’empaquetage et de transport utilisé par la plateforme Webtask ajoute de la latence. La taille a une incidence sur les performances du système.

​
Fonctions anonymes

Les scripts d’action peuvent être écrits sous forme de fonctions anonymes, mais ce n’est pas recommandé. Les fonctions anonymes rendent plus difficile le débogage du script d’action et l’interprétation de la pile d’appels générée en cas d’exception. Pour en savoir plus sur les fonctions anonymes, consultez IIFE sur MDN Web Docs.

​
Gestion des erreurs

Transmettez un objet Error à la fonction callback, accompagné d’un message décrivant l’erreur : 
return callback(new Error('My custom error message'));

​
Sécurité

​
Interface de base de données ou API

Veillez à sécuriser toutes les communications entre Auth0 et votre magasin d’identités hérité. Si votre magasin d’identités hérité ne dispose pas déjà d’une API, il est fortement recommandé d’en implémenter une. Si votre magasin d’identités hérité dispose d’une API, vous pouvez enregistrer l’API auprès d’Auth0 et créer une Action pour restreindre l’accès aux utilisateurs finaux. Si votre magasin d’identités hérité ne dispose pas d’une API — et qu’il n’est pas possible d’en implémenter une — vous pouvez tout de même communiquer directement avec votre base de données. Assurez-vous d’ajouter les adresses IP d’Auth0 à la liste d’autorisation de votre pare-feu pour autoriser le trafic entrant provenant d’Auth0.

​
Jetons du fournisseur d’identité

Si l’objet user renvoie les propriétés access_token et refresh_token, Auth0 les traite différemment des autres types d’informations utilisateur. Auth0 les stocke dans la propriété identities de l’objet user : 
{
	"email": "you@example.com",
	"updated_at": "2019-03-15T15:56:44.577Z",
	"user_id": "auth0|some_unique_id",
	"nickname": "a_nick_name",
	"identities": [ 
		{
			"user_id": "some_unique_id",
			"access_token": "e1b5.................92ba",
			"refresh_token": "a90c.................620b",
			"provider": "auth0", 
			"connection": "custom_db_name",
			"isSocial": false 
		}
  ], 
  "created_at": "2019-03-15T15:56:44.577Z",
  "last_ip": "192.168.1.1",
  "last_login": "2019-03-15T15:56:44.576Z",
  "logins_count": 3
}
Si vous voulez récupérer l’une de ces deux propriétés avec le d’Auth0, incluez le scope read:user_idp_tokens lorsque vous demandez un Jeton d’accès.