9

私は他の質問を読みましたが、それらは主にそうすることのセキュリティについて話しています。主に、Web サイトがブラウザベースのゲームであるという理由で、それは完全に私の関心事ではありません。ただし、より大きな問題はユーザーです。すべてのユーザーが OpenID を理解するのに十分な知識を持っているわけではありません。確かに RPX はこれを非常に簡単にします。私はこれを使用しますが、ユーザーが Google や Facebook などにアカウントを持っていない場合、またはシステムが既存のアカウントでログインすることを信頼していない場合はどうでしょうか? 彼らは別のプロバイダーでアカウントを取得する必要があります-私は、ほとんどの人がそれを行う方法を知っていると確信しています。

また、アプリケーションでどのように管理するかという問題もあります。ユーザーは 1 つのアカウントで複数の ID を使用したい場合があるため、ユーザー名 + パスワードを処理するほど単純ではありません。ユーザーの OpenID ID をデータベースに保存するにはどうすればよいですか? OpenID を使用すると、私にも利点があります。RPX は広範なプロファイル情報を提供できるため、プロファイル フォームを事前に入力し、必要に応じて編集するようにユーザーに依頼するだけです。

私は現在これを持っています：

Users:
------

ID     Email              Etc.
--     ---------------    ----
0      bob@yahoo.com      ...
1      alice@yahoo.com    ...

UserOpenIDs:
------------

ID     UserID     OpenID
--     ------     ------
0      0          0
1      0          2
2      1          1

OpenIDs:
--------

ID     Provider   Identifier
--     --------   ----------------
0      Yahoo      https:\\me.yahoo.com\bob#d36bd
1      Yahoo      https:\\me.yahoo.com\alice#c19fd
2      Yahoo      https:\\me.yahoo.com\bigbobby#x75af

これらの外部キーでは:

UserOpenIDs.UserID -> Users.ID
UserOpenIDs.OpenID -> OpenIDs.ID

データベースに OpenID 識別子を格納する正しい方法はありますか? RPX が提供した識別子をデータベース内の識別子と照合して、ユーザーにログインさせるにはどうすればよいでしょうか (識別子がわかっている場合)。

そこで、具体的な質問を以下に示します。

  • OpenID を持っていない、または使用したくないユーザーがアクセスできるようにするにはどうすればよいですか? （たとえば、Googleアカウントでログインするなどのセキュリティ上の懸念）
  • 識別子をデータベースに保存するにはどうすればよいですか? （上記の表が正しいかどうかはわかりません）
  • 誰かが別のユーザーとしてログインし、自分のアカウントで何かを喜んで行うのを防ぐために、どのような措置を講じる必要がありますか? （RPXはHTTP経由で識別子を送信することを理解しているので、誰かがしなければならないことは、どういうわけかそれを取得して「OpenID」フィールドに入力することです）
  • OpenID を使用する際に、他に注意する必要があることは何ですか?
4

3 に答える 3

4

アクセシブルにする

まず、OpenID を持っていないユーザーについては、アカウントの作成方法を説明する (またはいくつかのプロバイダーを指すこともある) 小さなページを作成できます。このように、OpenID アカウントを作成することは、通常のアカウントよりも難しくありません。

OpenID を使いたくない人には、2 つの選択肢があります。1 つ目: OpenID ログインの横に古いスタイルのログインを実装し、ユーザーが希望する方法を選択できるようにします。2 つ目は、OpenID のみを使用することです...これにより、作業が簡素化されます。信頼できる OpenID プロバイダーよりも Web サイトを信頼してログインするユーザーがいると言うのは、OpenID プロバイダーが暗号化された接続を使用することが多いため、私の意見では非常に奇妙です...

データベースへの格納

johnny gによって提案されたスキーマが必要です。(スラッシュの代わりにバックスラッシュを使用して URL を保存する理由がわかりません)

http://openid.test.com/abcとhttp://openid.test.com/abc/が別の URL として扱われるのを避けるために、URL を使用する前に正規化することをお勧めします。

追加の対策

なし。http://openid.net/developers/librariesのライブラリを使用するだけです。

ユーザーの身元の確認はプロバイダーの問題です。ユーザーと Web サイトのみがアカウントのパスワードを知っています。

誰かがあなたの OpenID URL (パブリック) を持っている場合でも、ログインするにはパスワード (または SSL 証明書などの別の種類の認証方法) が必要です。

于 2010-04-19T15:30:51.417 に答える
3

Arg、上記の私の以前のコメントに答えてください。

3 番目の質問「対策 ... 誰かが別のユーザーとしてログインするのを防ぐ ...」については、OpenId を理解しているので、信頼できないソースから OpenId Url を受け入れることは決してありません。実装では、あなたのサイトはプロバイダーのログインをホストし、プロバイダーのサイトはあなたに直接連絡するため、常に信頼できるサイトから OpenId Url を受け入れます。

つまり、悪意のあるユーザーがポケモンのように OpenId を収集したとしても、システムにアクセスする手段はありません。

2 番目の質問「どのように保存しますか?」に対しては、少しリラックスしたように見えますが、スキーマは機能します。たとえば、多対多のマッピング [つまりUserID to OpenID] を使用することで、1 人のユーザーが多数の OpenId に属することを許可し、1 つの OpenId が多数のユーザーに属することを許可します。後者なしで前者が必要です。

単純な外部キー制約で十分です。

UserID     Email        
------     --------------- 
86000      bob@yahoo.com 
86001      alice@yahoo.com 

UserID     Identifier 
------     ---------------- 
86000      https:\\me.yahoo.com\bob#d36bd 
86000      https:\\me.yahoo.com\bigbobby#x75af 
86001      https:\\me.yahoo.com\alice#c19fd

テーブルUserIDへの外部キーが指定され、Usersに一意のキー制約がありますIdentifier。これは基本的に、User0 個または多数の一意の を所有していることを示しますIdentifier。原則として、私はおそらくそのテーブルにも主キーを平手打ちしますが、それは面倒です。

お役に立てれば ：）

PS OpenId の統合または活用について疑問がある場合は、実装を進めてください。OpenId Url を取り込むすべてのソースを特定し、悪意のあるユーザーがそのエントリ ポイントにアクセスする可能性があるかどうかを自問してください。そのようなエントリ ポイントが 1 つだけあり、信頼できる OpenId プロバイダー以外はアクセスできないことを願っています。

于 2010-04-08T17:54:49.670 に答える
-1

最初の質問に対する 1 つの答えに気付きました。

ユーザーが OpenID を使用できない、または使用したくない場合は、既存のプロバイダーと提携して Web サイトで直接サインアップするか、自分でプロバイダーになります (ただし、これは、従来のユーザー名とパスワードのアカウントも持つことを意味し、ある種の見落としがあることを意味します)。質問のポイント-> OpenIDのみを使用）。

于 2010-04-08T17:25:47.847 に答える