J'ai lu les autres questions et ils parlent surtout de la sécurité de le faire. Ce n'est pas entièrement ma préoccupation, principalement parce que le site Web est question est un jeu basé sur le navigateur. Cependant, le problème plus vaste est l'utilisateur - et tous les utilisateurs sont suffisamment alphabés pour comprendre OpenID. Bien sûr, RPX rend cette assez facile, ce que j'utiliserai, mais que si l'utilisateur n'a pas de compte sur Google ou Facebook ou quoi que ce soit, ou ne faisant pas confiance au système à vous connecter avec un compte existant? Ils devraient avoir un compte sur un autre Fournisseur - je suis sûr que la plupart sauront comment le faire em>, encore moins être dérangés de le faire. Il y a aussi le problème de la façon de gérez-le dans l'application. Un utilisateur peut vouloir utiliser plusieurs identités avec un seul compte, il n'est donc pas aussi simple que celui d'utilisateur + mot de passe à traiter. Comment stocker les identités OpenID d'un utilisateur dans la base de données? Utilisation de OpenID me donne également une avantage: RPX peut fournir des informations de profil étendues, donc je ne peux que précharger le formulaire de profil et demander à l'utilisateur de modifier le besoin. P> J'ai actuellement ceci: p> UserOpenIDs.UserID -> Users.ID
UserOpenIDs.OpenID -> OpenIDs.ID
3 Réponses :
J'ai remarqué une réponse à la première question:
Si l'utilisateur ne peut pas ou ne veut pas utiliser OpenID, associez-les avec un fournisseur existant et les inscrivez directement sur le site Web, ou devenez moi-même un fournisseur (bien que cela signifie que cela signifie que les comptes de mot de passe classiques + sont également. genre de manque le point de la question -> utiliser uniquement OpenID).
arg, répondant mon commentaire précédent ci-dessus.
à votre troisième question "Mesures ... Pour empêcher que quelqu'un de se connecter à un autre utilisateur ...", comme je comprends OpenID, vous En d'autres termes, même si Un utilisateur malveillant recueille des openids comme Pokemon, ils n'ont aucun moyen par lequel accéder à votre système. à votre deuxième question "Comment puis-je stocker ..." Votre schéma fonctionnera, bien que cela semble un peu détendu . Par exemple, en utilisant un mappage de plusieurs à plusieurs [IE Une simple contrainte de clé étrangère suffira. fourni espère que cela aide :) PS Si vous avez des doutes d'intégrer ou de tirer parti de OpenID, puis sur une implémentation. Identifiez chaque peu de source qui prend une URL OpenID, puis demandez-vous s'il est possible qu'un utilisateur malveillant d'accéder à ce point d'entrée. J'espère qu'il n'y a qu'un seul point d'entrée et il est inaccessible à tout le monde, sauf les fournisseurs ouverts de confiance. userid à OpenID ], vous permettez à un utilisateur d'appartenir à de nombreux Openids et un seul openID appartenir à de nombreux utilisateurs. Vous voulez que le premier sans le dernier. userid est un étranger Touche de Utilisateurs TABLE ET Il existe une contrainte de clé unique sur Identificateur , cela indique essentiellement un utilisateur possédant zéro ou un identifiant unique < / code> s. Sur principe, je voudrais probablement gifler une clé primaire sur cette table aussi, mais c'est la sauce.
J'ai oublié userid dans la deuxième table. Fixé.
rendant cela accessible
Tout d'abord concernant les utilisateurs qui n'ont pas d'OpenID, vous pouvez créer une petite page qui explique comment créer un compte (ou même pointer sur certains fournisseurs). De cette façon, il n'est pas vraiment plus difficile de créer un compte OpenID qu'un compte régulier.
Pour les personnes qui ne veulent pas utiliser OpenID, vous avez deux choix.
Le premier: Implémentez un identifiant de style ancien à côté de votre connexion OpenID et laissez les utilisateurs choisir la méthode qu'ils souhaitent.
La seconde est d'avoir uniquement des Openids ... Cela simplifie votre travail.
Dire que certains utilisateurs font confiance à plus d'un site Web qu'un fournisseur OpenID de confiance pour vous connecter, est à mon avis assez étrange que les fournisseurs OpenID utilisent souvent des connexions cryptées, etc.
stocker dans la base de données
Le schéma proposé par Johnny G est ce dont vous avez besoin.
(Je ne sais tout simplement pas pourquoi stockez-vous des URL avec des barres obliques backslash au lieu de slashes)
Vous voudrez peut-être normaliser vos URL avant de les utiliser afin que vous puissiez éviter les choses comme http: //openid.test .Com / ABC et http://openid.test.com/abc/ être géré comme des URL différentes.
Mesures supplémentaires à prendre
aucun.
Vous devriez simplement utiliser une bibliothèque de http://openid.net/developers/libraires .
La confirmation de l'identité de l'utilisateur est le problème du fournisseur.
Seul l'utilisateur et le site Web connaissent le mot de passe sur le compte.
Si quelqu'un a votre URL OpenID (qui est public) , il a toujours besoin du mot de passe (ou d'un autre type de méthode d'authentification telle qu'un certificat SSL) pour pouvoir vous connecter.
J'ai utilisé les backslashes parce que c'est ce que RPX m'a donné via leur API. N'importe pas vraiment si longtemps que c'est cohérent. En ce qui concerne la bibliothèque, j'utiliserai RPX, qui dispose d'une API cohérente et d'une belle interface utilisateur.
Merci, je me demandais simplement pourquoi et comme vous dites que la question est d'avoir quelque chose de cohérent.
Hé là-bas, Nouveauté pour ouvrir moi-même, mais le considérant dans mon propre site. à votre troisième question « mesures ... pour empêcher quelqu'un de se connecter comme un autre utilisateur ... », comme je comprends OpenId, vous jamais accepter une OpenId URL à partir d'une source non fiable. Dans la mise en œuvre, votre site héberge le login d'un fournisseur, le site du fournisseur des contacts vous directement , vous acceptez donc une URL OpenID d'un site de confiance, toujours.