Discussion :

[slim]

Bonjour,

Je travaille sur une application web de gestion (Interface, formulaires etc. - serveur - bd). Les technos que j'utilise sont AngularJS, NodeJS et MongoDB.
L'application est sur le net mais je ne propose pas encore de démo pour les utilisateurs. Je voudrais leur proposer un login et un mot de passe du type ("demo", "demo") ou juste un bouton "Démonstration" pour qu'ils puissent accéder à la version de démo. Sur l'interface publique, il n'y a qu'une brève présentation, un form de contact etc.

Il existe plusieurs interfaces internes. Une fois que l'utilisateur enregistré est authentifié, il est redirigé sur une interface selon son rôle. Donc je pencherais plus sur un bouton ou une liste de choix de rôles (d'interfaces selon le rôle du user). L'utilisateur choisit le rôle qu'il veut voir et ouvre la démo.

Voila pour le contexte. Maintenant, la question que je me pose est : comment organiser cette version de démo techniquement ? en sachant que les utilisateurs se connectant sur une démo ne peuvent avoir les mêmes données !
Je crée une base vide ayant la même structure que la "réelle" et je la détruis une fois que l'utilisateur se déconnecte ? Dans ce cas, comment savoir si l'utilisateur s'est déconnecté ? Je crée un batch qui supprime les bd la nuit ?
Ou j'utilise la même bd mais avec des utilisateurs différents ? mais comment gérer ça au niveau de l'interface si j'ai un user : "demo", "demo" ou un bouton redirigeant vers la démo ?

Comment font les applis sur le web ?

Merci.

[slim]

Il n'y a personne qui est intéressé par le sujet...
C'est un projet personnel sur lequel je travaille et je n'ai pas encore attaqué ce tiquet...
Je pense gérer cela dans des cookies afin que l'utilisateur ouvrant la version de démo retrouve ses données lorsqu'il se reconnecte les fois suivantes.

[Luckyluke34]

Hello,

Je ne comprends pas trop... tous les utilisateurs doivent se connecter avec le même compte demo demo mais voir des données différentes ? J'ai rarement vu ça dans les applications de ce type qui se contentent en général d'afficher toutes les données qui ont été entrées par n'importe quel utilisateur démo, avec un vidage de la base tous les jours ou toutes les semaines.

[slim]

Merci pour ta réponse.
Mais je pense qu'il n'est pas utile de permettre à un utilisateur de voir les données (même si elle sont "fake") créées par un autre utilisateur qui a visité le site juste deux minutes avant... En plus, un utilisateur peut mettre n'importe quel mot dans les formulaires... Je ne voudrais pas qu'un deuxième utilisateur tombe dessus...

Je pense qu'une démo doit être faite à partir d'une base vierge. Et puisque l'utilisateur saisit des données, pourquoi ne pas les enregistrer pour qu'il les retrouve plus tard tout en limitant les données à enregistrer.

[Luckyluke34]

Ouais... du coup, si le login ne suffit pas à identifier un utilisateur, il faut introduire un autre discriminant donc effectivement pourquoi pas un cookie. Mais ça va t'obliger à introduire une dérogation dans ton système qui en prod normale est censé uniquement se baser sur le login...

Comme je disais, ce qui se fait la plupart du temps c'est soit demander à l'utilisateur de s'enregistrer et lui envoyer des identifiants custom du genre demo1988789, soit afficher les données de tout le monde mais je n'ai jamais vu la solution par cookie.

[tdutrion]

Sinon tu crées un système d'authentification externe (une page ou tu demandes un identifiant, ou alors une page qui génère un ID unique), et avec cet id unique tu spawn un container docker qui contient l'application avec un compte demo/demo pre-enregistré. L'utilisateur utilises alors l'adresse id.domaine.com pour aller sur sa version de demo.

Ensuite, tu lances jwilder/nginx-proxy pour faire le proxy, et utilises -e VIRTUAL_HOST=id.domaine.com pour lancer les containers.

Pour ne pas déranger tes autres services, tu lances ça sur une box séparée genre VPS SSD 1 chez OVH (un truc assez cheap), ou bien un digital ocean ou linode... Comme ça si t'es spammé ça casse juste tes demos.

Il te faut bien entendu un cron qui kill les containers après une semaine.

[slim]

Mais ça va t'obliger à introduire une dérogation dans ton système qui en prod normale est censé uniquement se baser sur le login...

Remarque intéressante...
Oui, en prod je me base uniquement sur le login. Je ne comptais pas faire le test sur le login. Mais enregistrer une clé dans le cookie identifiant le type de compte (prod, démo).
Mais réflexion faite, cela revient au même...

Au niveau de la présentation (AngularJS), je dispose (déjà) des informations de l'utilisateur (username uniquement et quelques données métier) avec un token JWT pour l'authentification et les autorisations d'appels au serveur.
Je pourrais me baser soit sur le login (si c'est démo), soit sur la présence ou pas du token. S'il est absent, cela voudrait dire que c'est une démo.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if(!token)
    cookieService.save(data);
} else {
    httpService.save('//domain...');
}

[Logan Mauzaize]

Vu que tu as une base MongoDB, specifie un TTL sur les données temporaires.

Pour isoler les personnes, remplace le formulaire login/mdp par un identifiant autogénéré. S'il doit y avoir un réel cloisonnement des utilisateurs, il convient mieux comme suggéré de démarrer de nouvelles instances. C'est le meilleur moyen de gérer le multi-tenant.

[slim]

Merci à vous deux.
Je ne savais pas qu'on pouvait automatiser la suppression des documents dans MongoDB
Je vais effectivement utiliser cette option et vais creuser la solution proposée par Théocrite.

Et juste une précision. Je pense que vous vous en êtes aprçu :
Quand je parlais d'utilisateurs, je voulais parler bien entendu de visiteurs non authentifiés...