Authentification des utilisateurs sur une application à page unique ?

Question

J'ai développé un prototype d'application à page unique qui utilise Backbone sur le front-end et qui va consommer des données à partir d'une API RESTful sur le serveur.

Venant du développement lourd d'applications côté serveur (php et python), j'ai vraiment apprécié la nouvelle approche de conception différente avec un MVC côté client lourd, mais je ne sais pas comment limiter l'application aux utilisateurs authentifiés qui se connectent.

Je préfère avoir l'application elle-même derrière un login et j'aimerais aussi implémenter d'autres types de logins à terme (openid, fb connect, etc) en plus du login natif du site. Je ne sais pas comment cela se fait et j'ai cherché - sans succès - des informations qui me permettent de comprendre.

Dans l'ensemble, quelle est la meilleure pratique actuelle pour enregistrer les utilisateurs et leur demander de se connecter pour utiliser votre application à page unique ?

Une fois qu'un utilisateur est connecté, comment les demandes d'api sont-elles authentifiées ? Puis-je stocker une session mais comment détecter cette session dans les appels d'API ou y a-t-il un jeton que je dois passer dans chaque appel d'API ? Toute réponse à cette question serait très appréciée !

Answer 1

La méthode la plus RESTful que j'ai vue est basée sur le flux d'informations d'identification du client OAuth, essentiellement un point de terminaison /token auquel vous envoyez le nom d'utilisateur/mot de passe et qui renvoie un jeton d'accès pour cette session. Chaque requête ajax après cela ajoute un Authorization l'en-tête du porteur avec le jeton. Vous pouvez stocker le jeton dans une variable globale pour le conserver jusqu'à ce que la page soit rafraîchie/fermée, utiliser un stockage local pour que les utilisateurs restent connectés entre les sessions, ou des cookies javascript. Si vous n'aimez pas l'idée des jetons, vous pouvez simplement utiliser l'ancienne approche des cookies qui sont de toute façon envoyés automatiquement avec toute requête ajax.

Pour ce qui est de facebook/google etc., je suis normalement l'approche de stackoverflow qui consiste à associer des identifiants externes à un compte. Ensuite, j'utilise une danse oauth assez normale basée sur le serveur (bien que vous puissiez remplacer toutes les demandes au serveur par des demandes ajax avec de légères modifications, je trouve que cela ne fait pas vraiment de différence car vous avez besoin de redirections entre vous et le serveur de toute façon). Je délivre normalement un cookie crypté pour une connexion facebook, que je convertis ensuite en jeton en utilisant une méthode similaire à celle décrite ci-dessus (envoyez simplement le cookie avec la requête au lieu du nom d'utilisateur/mot de passe).

Answer 2

Nous utilisons l'authentification basée sur les cookies de Django et avons une page séparée pour la connexion et l'application à page unique. Cela fonctionne assez bien pour notre cas d'utilisation. Nous avons utilisé un système de gestion de session basé sur Backbone que j'ai décrit ici : backbone.js - gérer si un utilisateur est connecté ou non

Answer 3

Nous utilisons Angular.js et avons également une page séparée pour la connexion. La page séparée charge une application séparée à page unique (et sécurisée), qui appelle le serveur en utilisant une requête http XHR, en envoyant le nom d'utilisateur et le mot de passe. Si le serveur authentifie les informations d'identification, le code javascript crée un cookie. Ce cookie peut être lu de "l'autre côté", c'est-à-dire de l'application non sécurisée. Dans le cookie, nous ne mettons que le nom d'utilisateur et bien sûr, pas de mot de passe ou d'autres informations sécurisées. nous pouvons alors afficher quelque chose comme "Pas Lior ? Déconnexion" sur l'application non sécurisée.

La seule chose à noter est d'outrepasser le mécanisme de cookies d'Angular pour définir une expiration indéfinie et, plus important encore, le chemin de la racine :

$document[0].cookie = 'username=' + escape($scope.userName) + ";expires=Thu, 01 Jan 2970 00:00:00 GMT; Path=/";