Remarque : les stratégies décrites dans cet article peuvent être utilisées pour migrer des utilisateurs à partir d'une autre application, d'un environnement de serveur brainCloud distinct ou même d'une plate-forme back-end complètement différente.
Souvent, lors du développement d'une nouvelle version d'une application, il est utile de la tester en version bêta indépendamment de votre application brainCloud de production.
En apparence, c'est simple. brainCloud vous permet d'avoir plusieurs versions de votre application et de transférer les mises à jour de configuration d'une application à l'autre. En fait, c'est ainsi que la plupart des développeurs gèrent le cycle de développement standard : développement > tests > préproduction > production.
Mais que faire si vous souhaitez que les utilisateurs utilisent leurs données d'application existantes pour la version bêta ? Cela permet une version bêta bien plus performante (tant du point de vue de l'utilisateur final que du test), mais cela est difficile à réaliser dans brainCloud, car toutes les données utilisateur sont stockées indépendamment pour chaque application brainCloud.
Idéalement, le cas d'utilisation serait :
Installer le client bêta (en écrasant potentiellement le client de production sur leur appareil)
Lancement du client bêta : il se connecte à l'application bêta brainCloud et transmet les identifiants d'authentification de l'utilisateur. Voici ce qui se passe sur le serveur :
L'authentification échoue (car l'utilisateur n'a pas encore de profil/compte dans l'application bêta )
Le serveur doit se connecter à l'application de production et vérifier si l'utilisateur y possède un compte.
Si l'utilisateur * possède * un compte sur l'application de production, les données de production de l'utilisateur doivent être retournées - afin que nous puissions créer un profil/compte pour l'utilisateur dans l'application bêta
Nous retournons ensuite l'authentification réussie au client bêta, en le connectant à son profil/compte d'application bêta nouvellement créé.
Cet article fournit des instructions étape par étape sur la manière de réaliser ce cas d’utilisation.
Notez que cet exemple démontrera le transfert de l'identité de l'e-mail de l'utilisateur avec des entités usager uniquement, mais il peut également être étendu à d'autres types d'informations d'identification et à d'autres données utilisateur (telles que les fichiers usager).
Notez également que nous recommandons de limiter cette migration aux comptes d'utilisateurs finaux utilisant uniquement des identités fortes (c'est-à-dire non anonymes). Réaliser ce cas d'utilisation avec des identifiants anonymes est plus problématique ; il faudra donc veiller à préserver les identifiants anonymes d'origine de l'utilisateur. Dans le cas contraire, l'accès à son profil/compte de production risque d'être perdu lors du retour à la version de production de l'application.
Ainsi, notre forte recommandation est d'autoriser ce mécanisme uniquement pour les utilisateurs disposant d'identités appropriées (e-mail, universalId, Facebook, etc.) attachées à leurs comptes.
---
Pour configurer la migration de compte
Dans votre application source (qui contient l'identité de messagerie électronique existante de l'utilisateur et les entités usager) :
Tout d'abord, créez le script exécutable S2S suivant dans votre application source pour valider les informations d'identification transmises via l'appel S2S depuis votre application cible (votre nouvelle application) et retournez
profileId
etuserEntities
à l'appelant. Ce script est décrit comme un commentaire en ligne. ( Notez que ce script est nommévalidateAndExportUser
sous le répertoireretrieveuserdata
; nous y ferons référence ultérieurement depuis l'appelant.)"use strict";
function main() {
var response = {};
// success: false sera retourné si les informations d'identification sont erronées.
// {
// "duration": 113,
// "data": {
// "response": "Script Error (Line 17, Column 0): Wrapped com.braincloud.common.ProcessingException: Token does not match user.",
// "success": false
// },
// "status": 200
// }
// et ce script arrêtera d'exécuter le reste du code sous cet appel.
var session = bridge.getSessionForValidatedCredential(data.externalId, data.authenticationType, data.externalAuthType, data.authenticationToken);
bridge.logInfo("the session from getSessionForValidatedCredential-", session.toString());
// puis utilisez sysGetUserExport pour récupérer les entités utilisateur et les renvoyer à l'appelant
var playerId = session.playerId;
response.playerId = session.playerId;
var optionsJson = {"includeEntities": true};
var userProxy = bridge.getUserServiceProxy();
var postResult = userProxy.sysGetUserExport(playerId, optionsJson);
if (postResult.status == 200) {
bridge.logInfoJson("the return from sysGetUserExport...", postResult);
bridge.logInfoJson("the return from postResult.data[playerId]...", postResult.data[playerId]);
response.aEntities = postResult.data[playerId].childEntities;
}
return response;
}
main();Créez un serveur S2S dans votre application source si vous n'en avez pas. Nous l'utiliserons pour appeler les scripts S2S créés à l'étape précédente.
Assurez-vous qu’il existe plusieurs utilisateurs avec une identité de messagerie et que ces utilisateurs ont des entités usager dans votre application source.
Dans votre application cible (vers laquelle vous souhaitez transférer les informations d'identification et les données utilisateur) :
Créez un script hook dans votre application cible, comme indiqué ci-dessous, pour effectuer le transfert. Il est décrit comme un commentaire en ligne. ( Notez que ce script est invoqué comme un hook postFail d'authentification ; nous pouvons obtenir le même résultat en utilisant un pré-hook, selon votre cas d'utilisation. )
"use strict";
// il s'agit d'un script déclenché par un hook postFail d'authentification, utilisez-le pour vérifier les informations d'identification de l'e-mail de l'utilisateur à partir d'une application source et copiez les données utilisateur - entité usager pour cet exemple.
function main() {
var response = {};
bridge.logInfoJson("Script inputs", data);
// utilisation des informations d'identification de l'e-mail de l'utilisateur pour cet exemple
// il invoquera l'appel s2s à l'application source 24667
var emailAddress = data.callingMessage.externalId;
var passWord = data.callingMessage.authenticationToken;
var authenticationType = data.callingMessage.authenticationType;
var externalAuthType = data.callingMessage.externalAuthName;
var httpProxy = bridge.getHttpClientServiceProxy();
// validation et récupération du profileId de l'utilisateur à partir de l'application source
var serviceCode = "bcs2sdispatcher";
var path = "";
var headers = {
"Content-Type": "application/json"
};
var appId = data.parms.appId;
var serverName = data.parms.serverName;
var serverSecret = data.parms.serverSecret;
var jsonForScriptRun = {
"appId": appId,
"serverName": serverName,
"serverSecret": serverSecret,
"service": "script",
"operation": "RUN",
"data": {
"scriptName": data.parms.scriptInSourceApp,
"scriptData": {
"externalId":emailAddress,
"authenticationToken":passWord,
"authenticationType":authenticationType,
"externalAuthType":externalAuthType
}
}
};
var userProfileIdInSourceApp = "";
var userProfileIdInCurrentApp = "";
var userEntitiesArry = [];
var postResultScriptRun = httpProxy.postJsonResponseJson(serviceCode, path, headers, jsonForScriptRun);
if (postResultScriptRun.status == 200 && postResultScriptRun.data.json.success) {
bridge.logDebugJson("postResultScriptRun return...", postResultScriptRun);
userProfileIdInSourceApp = postResultScriptRun.data.json.response.playerId;
userEntitiesArry = postResultScriptRun.data.json.response.aEntities;
}
if (userProfileIdInSourceApp) {
// créer les informations d'identification de l'utilisateur (à l'aide de sysCreateUserEmailPassword) dans l'application actuelle avec notification -- d-a2160e8c27aa454288a03fcd6fc30163
var userProxy = bridge.getUserServiceProxy();
var postResultUserCreate = userProxy.sysCreateUserEmailPassword(emailAddress, passWord, emailAddress.split('@').shift(), "d-a2160e8c27aa454288a03fcd6fc30163");
if (postResultUserCreate.status == 200) {
userProfileIdInCurrentApp = postResultUserCreate.data.profileId;
var userSession = bridge.getSessionForProfile(userProfileIdInCurrentApp);
bridge.logDebug("userSession", userSession.toString());
var entitiesCount = 0;
if (userEntitiesArry.length > 0){
var entityProxy = bridge.getEntityServiceProxy(userSession);
userEntitiesArry.forEach(entity=>{
var postResultCE = entityProxy.createEntity(entity.entityType, entity.data, entity.acl);
if (postResultCE.status == 200) entitiesCount++;
});
}
bridge.logDebug("entitiesCount:"+entitiesCount, entitiesCount);
response.entitiesCreatedCount = entitiesCount;
}
}
// indicateur de clé, utilisant le statut 199 pour forcer une nouvelle tentative d'authentification
response.status = 199;
return response;
}
main();(Les paramètres d'admission comme vous pouvez le voir, plusieurs paramètres sont extraits de l'API d'authentification --
"externalId", "authenticationToken", "authenticationType", and "externalAuthType"
--, et plusieurs paramètres sont extraits du hookedparms
, s'afficheront à l'étape suivante).Accrochez le script que vous avez créé à partir de l’étape ci-dessus pour authentifier l’API via la page Hooks API de la console brainCloud.
(Notez que
appId
est votre application source, mettez le nom de votrecustom server
que vous avez créé dans votre code source à partir de l'étape ci-dessus àserverName
et le secretcustom server
dans les champsserverSecret
respectivement, ainsi que le nom du script pour transférer les entités usager et valider les informations d'identification en conséquence dans les champsscriptInSourceApp
).
Depuis la page Liste blanche des services Web de la console brainCloud, créez un service nommé "
bcs2sdispatcher
" et attribuez-lui l'URL du répartiteur brainCloud S2S.
L'URL appropriée est la suivante :https://sharedprod.braincloudservers.com/s2sdispatcher
Vous pouvez également configurer SendGrid pour votre application cible et configurer un modèle de notification dans votre console SendGrid afin que les utilisateurs finaux puissent recevoir une notification par e-mail une fois leur création effectuée. ( Notez que pour remplacer l'ID du modèle d'e-mail dans le script ci-dessus par votre ID de modèle d'e-mail pour la méthode
sysCreateUserEmailPassword
).
Test
Une fois toutes les configurations terminées dans les applications source et cible, vous pouvez les tester via l'explorateur d'API de la console brainCloud ou dans votre application cible cliente. Vous pouvez définir à
false
un paramètre d'authentificationforceCreate
pour vérifier un utilisateur final qui n'existe pas dans votre application cible, mais qui est présent dans votre application source. Vous pouvez vérifier que l'utilisateur est connecté, même si la valeur deforceCreate
est définie sur "false".Vérifiez également les entités usager pour ce nouvel utilisateur à partir de la page Usager > Données > Entités de l'usager, vous constaterez que les entités usager y sont également transférées depuis l'application source.
Testez en plaçant des informations d'identification erronées (non existantes dans votre application source) pour authentifier un utilisateur final, et comme prévu, vous êtes bloqué lors de la connexion.