Utilisation d'un sous-domaine de site Web pour se connecter aux utilisateurs

Question

Fogbugz-on-demand, 37 signaux, et PB-Wiki utilisent tous des sous-domaines avec des URL personnalisées pour chaque groupe d'utilisateurs pour accéder à leur page de connexion. Il ne semble donc même pas possible pour un utilisateur utilisant ces services de se connecter à un login generc (que tout utilisateur du service pourrait se connecter.)

Au début, je pensais que c'était un défaut de conception terrible, mais maintenant je pense que c'est une très bonne idée à cause de: 1) sécurité supplémentaire, il peut ne pas être beaucoup, mais vous avez besoin de 3 informations: 1 sous-domaine url, 2 login, 3 mot de passe

2) Vous pouvez laissez le même login se connecter dans différents comptes par l'URL de sous-domaine.

3) Cela se traduit par plus d'isolation, d'équilibrage de la charge et de facilité de déploiement, car les sous-domaines peuvent s'exécuter sous différents serveurs en étant plus isolés les uns des autres.

4) Vous pouvez déployer progressivement les modifications apportées à un ensemble donné de sous-domaines marqués en tant qu'utilisateurs BETA avant de les déployer sur tous les utilisateurs.

Les connexions de sous-domaine pour les applications Web sont-elles le futur? Y a-t-il des pièges avec cette approche de conception que je ne vois pas? Est-ce trop déroutant pour les utilisateurs non programmeurs de comprendre le concept de sous-domaine?

Answer 1

Nous sommes allés avec un login triple-élément à la place. Nous demandons le nom d'utilisateur, le mot de passe et l'identifiant client. Même concept que les sous-domaines, mais il existe une URL de connexion commune. Cela fonctionne bien aussi. Cependant, je vois un avantage dans le processus de sous-domaine, vous pouvez marquer la page de connexion parce que vous connaissez le client demandé. Dans notre approche, nous ne pouvons pas marquer la page de connexion, car nous ne connaissons pas le client tant que vous n'avez pas soumis la page de connexion.