Pourquoi faire de la page de connexion à une application d'une seule page une page séparée?
Je me demande pourquoi il semble populaire que la page de connexion d'un SPA soit une page distincte qui ne fait pas partie du SPA (comme dans le cas des données chargées et envoyées via des requêtes ajax)?
La seule chose à laquelle je peux penser est la sécurité, mais je ne peux pas penser à une raison de sécurité spécifique. Je veux dire que la seule chose qui me vient à l'esprit est que si votre page de connexion fait partie du SPA, elle envoie le nom d'utilisateur/mot de passe via ajax qui peut être vu par des outils tels que Firebug ou Web Inspector; cependant, même si vous l'envoyez en tant que POST normale, il existe d'autres outils qui peuvent facilement capturer ces données (comme violoneux, httpscoop, etc.).
Y a-t-il quelque chose qui me manque?
Vraisemblablement, c'est pour sauver le chargement d'un tas d'actifs côté client (comme les cadres JavaScript lourds, les images, etc) qui ne sont requis que par l'application.
Il existe des moyens plus sophistiqués pour atteindre un objectif de performance similaire (voir " Malte Ubl & John Hjelmstad: Une nouvelle approche efficace du chargement de JavaScript - JSConf EU 2012 ") mais cela est assez rapide à mettre en œuvre et sans doute tout aussi efficace, surtout si votre application Web utilise de toute façon presque tous vos actifs.
Vous pouvez le voir à l'état sauvage dans un site comme le http://infogr.am beta:
- http://infogr.am/login/ charges jquery, raphael, js personnalisés et 3 fichiers css.
- http://infogr.am/beta/ (la page principale SPI pour l'application) charge 10 frameworks javascript, 5 fichiers css externes et environ 60 images.
Je pense qu'il y a des arguments raisonnables pour ou contre, et je dirais que la technologie joue également un rôle dans la décision.
On pourrait dire que le fait d'avoir une "page" de connexion distincte permet d'utiliser la "sécurité de répertoire". En général, tout le monde peut voir la "page" de connexion, mais seuls les utilisateurs authentifiés peuvent voir la "page" de l'application et son "répertoire". Les itinéraires peuvent également être verrouillés, où/Account/est différent de/App/et chacun a son propre "profil" de sécurité.
De plus, si vous utilisez une approche SPA et que vous mélangez l'authentification avec l'expérience d'application, la logique pourrait être compliquée. Au lieu de supposer que l'utilisateur est "connecté parce qu'il est ici", vous devez constamment vérifier son état d'authentification et demander "si cet utilisateur est ici".
De plus, la page de connexion se trouve généralement sur le site destiné aux consommateurs. Vous allez sur www.yourapp.com et elle contient des informations, des contacts, du support, etc. et une page "connexion" .. à partir de la page de connexion, après l'authentification, vous pouvez rediriger vers une multitude de cibles ..
La raison pour laquelle je garde une page de connexion séparée et pourquoi j'ai en fait une application entièrement différente pour mon site "destiné aux consommateurs" est parce que je peux exposer très peu aux utilisateurs non authentifiés. Par hasard, un crétin commence à frapper sur ma page de connexion, je ne veux pas que cela affecte le côté application des choses .. même si la connexion ne fait qu'une simple recherche d'authentification .. cela m'aide en quelque sorte à empêcher les bozo d'affecter mon l'expérience des utilisateurs .. Pire cas, mon site consommateur tombe en panne et personne ne peut se connecter, mais au moins les utilisateurs connectés ne le sauront pas et leur expérience ne commencera pas à ralentir .. Je ne dis pas que c'est le choix à l'épreuve des balles .. mais au moins j'ai isolé le risque pour la zone non authentifiée ..
Une des raisons pour cela est que vous pouvez ensuite utiliser des sessions normales basées sur les cookies. L'utilisateur se connecte, la réponse envoie un cookie avec la page principale initiale ... puis tous les appels ajax ultérieurs renvoient le cookie au serveur.
Je vois quelques raisons de le faire:
- Je peux utiliser des règles de contrôle d'accès basées sur un chemin normal dans web.xml.
- Je ne peux jamais être sûr d'avoir correctement protégé toute mon application Ajax, et je dois faire des tests approfondis pour être confiant.
- Je peux déléguer l'authentification à un framework (comme Spring Security), une application tierce ou une solution SSO (comme CAS ou JOSSO).
- Je peux laisser le navigateur mettre en cache le nom d'utilisateur et (éventuellement) les mots de passe de l'utilisateur.