Pourquoi faire de la page de connexion à une application d'une seule page une page distincte?

28

Je me demande pourquoi il semble être populaire que la page de connexion d'un SPA soit une page distincte qui n'est pas la page du SPA (comme dans le cas des données chargées et envoyées via des requêtes ajax)?

Je ne pense qu'à 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, même si vous l'envoyez normalement Demande POST, 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?

javascript architecture

— ryanzec
source

2

Je ne pense pas qu'il y ait ou ait besoin d'une raison dans ce cas. Je dirais, pourquoi pas?

— Steven Evers

1

Mon argument contre serait que le fait d'avoir la page de connexion en tant que page html distincte tandis que le reste de l'application est une architecture SPA semble étrange sans réel avantage (bien que le point soulevé par msanford ait du mérite).

— ryanzec

@ryanzec Merci. J'ai ajouté un exemple pour tenter d'illustrer qu'il y a un réel avantage. Premièrement, les économies liées au report du chargement des actifs ailleurs ne sont pas négligeables, en particulier en cas d' échec de connexion (ou de suspension de compte, etc.). Deuxièmement, il est beaucoup plus rapide à implémenter qu'un système de modules basé sur les dépendances asynchrones plus sophistiqué, et le cycle de vie du développement est une considération importante (voir le mantra de bureau d'Opbeat * (contient la vulgarité)).

— msanford

"même si vous l'envoyez comme une demande POST normale, il existe d'autres outils qui peuvent facilement capturer ces données". Votre formulaire de connexion est sûrement protégé par HTTPS ?

— ajlane

@ajlane oui, ma connexion (et en fait, toute l'application) va s'exécuter derrière HTTPS

— ryanzec

18

Vraisemblablement, c'est pour économiser 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 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 la http://infogr.am beta:

http://infogr.am/login/ charge jquery , raphael , js personnalisés et 3 fichiers css.
http://infogr.am/beta/ (la page SPI principale de l'application) charge 10 frameworks javascript, 5 fichiers css externes et environ 60 images.

— msanford
source

Mise à jour: En 2016 avec le front-end angular2 et un back-end JBoss, nous le faisons toujours pour la même raison.

— msanford

18

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 faire valoir 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 est 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. l'authentification, vous pouvez rediriger vers une multitude de cibles ..

La raison pour laquelle je garde une page de connexion distincte 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 ..

— hanzolo
source

1

La sécurité est souvent une grande raison.

— JustinC

1

@JustinC: expliquez-moi sur une page séparée pour vous connecter de manière plus sécurisée?

— ryanzec

Pas nécessairement par le biais d'attributs de système de fichiers (mais cela peut l'être si c'est ce que la situation appelle), mais le logiciel d'application / conteneur / servlet d'application Web via l'application d'authentification sélective / méthodes d'autorisation appliquées soit sur une ressource spécifique, soit sur un groupe de ressources dans son ensemble (en termes pratiques, un répertoire): pour la page de connexion et des ressources statiques particulières (images, feuilles de style, pages d'erreur), un accès anonyme est souvent suffisant; pour les autres pages, une authentification / autorisation plus particulière peut être requise.

— JustinC

2

L'authentification en dehors de l'application isole l'authentification de toute préoccupation de l'application. La sécurité réelle dépendra de la mise en œuvre et de la technologie

— hanzolo

mise à jour 2017: IdentityServer

— hanzolo

10

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.

— GrandmasterB
source

6

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.

— n0rm1e
source