Meilleures pratiques pour les bases de données personnalisées et l’exécution des scripts d’action

Un type de connexion à une base de données personnalisée vous permet de configurer des scripts d’action, qui contiennent le code personnalisé qu’Auth0 utilise pour assurer l’interface 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.

Les scripts d’action s’exécutent dans un conteneur Webtask individuel avec une limite d’exécution d’environ 20 secondes. Après l’exécution des fonctions, le conteneur est recyclé.

Lorsqu’un conteneur est recyclé, il met fin aux opérations en cours du script d’action. Cela peut entraîner le retour d’une condition d’erreur et une réinitialisation potentielle de l’objet global. Pour plus d’informations sur l’objet global, lisez Meilleures pratiques de l’environnement des scripts d’action des bases de données personnalisées.

Les fonctions 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 fonctions 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 à toutes les opérations en attente, ce qui peut entraîner un comportement inattendu ou une erreur.

Si vous appelez un service externe ou une API dans votre script d’action, paramétrez la fonction pour qu’elle se termine après une durée raisonnable et renvoyez une erreur si le service externe ou l’API ne peut pas être atteint.

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

Cet exemple utilise la méthode intégrée JavaScript fetch, qui obtient une ressource à partir d’un réseau et renvoie un objet Promise, écrit à l’aide de chaînes Promise.

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}`));
		});
  }

Cet exemple utilise la méthode intégrée JavaScript fetch, qui obtient une ressource d’un réseau et renvoie un objet Promise, écrit à 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);
}

La fonction callback signale que l’opération 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 un appel à la fonction callback, de préférence en utilisant explicitement l’instruction return.

Si un script d’action utilise un traitement asynchrone, la fonction callback doit être appelée après la fin de toutes les opérations asynchrones.

Si la fonction callback est appelée sans paramètre, elle sera exécutée comme si un paramètre null avait été fourni.

La taille totale de la mise en œuvre d’un script d’action ne doit pas dépasser 100 Ko. Cette limitation de taille exclut les modules importés npm. Pour plus d’informations sur les modules npm, lisez Meilleures pratiques de l’environnement des scripts d’action des bases de données personnalisées.

Plus la taille d’un script est importante, plus la latence est introduite en fonction du processus d’emballage et de transport utilisé par la plateforme Webtask. La taille a un impact sur les performances du système.

Les scripts d’action peuvent être mis en œuvre sous forme de fonctions anonymes, mais il n’est pas recommandé du faire. Les fonctions anonymes compliquent le débogage du script d’action et l’interprétation de la pile d’appels générée à la suite d’une condition d’erreur exceptionnelle. Pour en savoir plus sur les fonctions anonymes, lisez IIFE sur MDN Web Docs.

Transmettez un objet Error à la fonction callback avec un message descriptif de l’erreur :

return callback(new Error('My custom error message'));

Veillez à sécuriser toutes les communications entre Auth0 et votre magasin d’identité hérité. Si votre magasin d’identité hérité n’a pas encore mis en œuvre une API, il est fortement recommandé de le faire.

Si votre magasin d’identité hérité dispose d’une API, vous pouvez enregistrer l’API via Auth0, et créer une Action pour restreindre l’accès des utilisateurs finaux.

Si votre magasin d’identité hérité ne dispose pas d’une API et qu’il n’est pas possible d’en mettre une en œuvre, vous pouvez toujours communiquer directement avec votre base de données. Veillez à ajouter les adresses IP d’Auth0 à la liste d’autorisations de votre pare-feu pour autoriser le trafic entrant en provenance d’Auth0.

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 souhaitez récupérer l’une de ces propriétés avec le Management API Auth0, incluez la permission read:user_idp_tokens lorsque vous demandez un jeton d’accès.