RESTE l'authentification de l'utilisateur
OK... l'idée de base est d'avoir le SERVEUR et le CLIENT physiquement séparés (deux systèmes).
Mon idée est de construire un stand-alone web services (REST, XML, API-KEY) qui fournira
- D'authentification: l'Utilisateur de connexion, de déconnexion
- De données: Obtenir la liste des produits
Alors je vais créer des clients dans différentes langues (Flash, PHP, JavaScript). Les données seront servis uniquement aux utilisateurs authentifiés.
Typiques de la communication pour l'utilisateur pour obtenir la liste des produits seront les suivants:
- (1 demande) Login /début de la session
- (1 demande) Obtenir la liste des produits
- (1 demande) Obtenir la liste des produits
- ...
OK... Maintenant le problème que j'ai est la session de l'utilisateur. Disons que nous voulons construire Javascript client, nous avons à créer PHP client de communiquer avec le RESTE (PHP sait à propos de l'API REST-CLÉ) et transmet les informations à Javascript (CLIENT) droit? L'utilisateur se connecte par le biais de PHP pour se REPOSER un serveur et ensuite les données de la demande par le biais de PHP pour se REPOSER serveur?
Questions:
- Maintenant, comment fonctionne PHP stocker des informations sur ouverture de session utilisateur sur le RESTE du serveur?
- Si mon idée est mauvaise, quelle est la bonne façon de la mise en œuvre?
- Alternatives?
(1) d'Envoyer à l'utilisateur des informations d'identification avec tous à la demande, via le protocole HTTPS. (2) Utiliser un existant, pratique et sécurisé d'authentification de la bibliothèque. Par exemple, prendre un coup d'oeil à github.com/delight-im/PHP-Auth qui est à la fois un cadre indépendant et de base de données agnostique. (3) connectez-vous. (4) Faire le travail sur votre serveur. (5) connectez-vous de nouveau.
OriginalL'auteur xpepermint | 2009-09-21
Vous devez vous connecter pour publier un commentaire.
Une interface RESTful ne stockons pas d'informations sur une session utilisateur. Il appartient au client de conserver les informations sur ce qu'il est en train de faire.
D'authentifier l'utilisateur sur chaque demande en fournissant de l'information dans l'Autorisation d'en-tête HTTP. SI cela devient un problème de performance, puis envisager d'autres solutions pour optimiser les perf.
OriginalL'auteur Darrel Miller
À votre première question: XmlHttpRequest demandes pour un service encore passer le long de cookies, qui peut être utilisé pour propager un ID de session. Vous pouvez même (en supposant que l'utilisateur du navigateur prend en charge) marque de cookies comme "HttpOnly" pour réduire votre XSS empreinte. Voir Jeff Atwood de l'article pour le détail sur l'.
Vous pouvez toujours stocker l'état sur le client et d'être de tout repos. La seule restriction est que l'état de l'application ne doit pas être stocké sur le serveur.
Dans ces discussions, il est important de faire la distinction l'état de l'application (état de session) à partir de ressources de l'état. Dans un cadre Reposant de l'architecture, des ressources de l'état est stocké côté serveur, alors que l'état de l'application est stocké côté client. [infoq.com/articles/mark-baker-hypermedia]
OriginalL'auteur TML
Vous devriez probablement utiliser l'authentification HTTP pour l'authentification de l'utilisateur, et donc pas besoin de faire une sorte de gestion de session.
OriginalL'auteur Ciaran McNulty
Vous n'avez pas besoin de PHP pour stocker une API-KEY si vous faites votre client classes en javascript assez intelligent pour ajouter l'API-KEY (chargé lors de la connexion) dans les en-têtes de chaque XmlHttpRequest votre classe se frayer.
Aussi, il pourrait être bon de noter que l'API-KEY n'est pas nécessairement la clé d'authentification.
OriginalL'auteur Martijn Laarman
Je suis face au même problème. J'ai utilisé restserver en php.
Bien sûr, le trafic va plus de connexion SSL.
Quand je voudrais obtenir des informations sur certaines utilisateur doit s'authentifier en premier pour le reste du serveur avant que je puisse obtenir son info. Je voudrais savoir tout mieux approches?
Poste similaire: Réparateur D'Authentification
Bonne ressource est également OAuth2.
Google utilise oauth:
Lorsque l'application utilise ceci: http://restserver/user/login et disons que l'authentification est ok, l'application crée lui-même session comme ceci:
Reste client/Application
Reste Du Serveur
OriginalL'auteur broadband