1

RPXサードパーティ フェデレーション ID システムを統合したばかりの ASP.NET MVC アプリケーションがあります。統合は問題なく機能していますが、ASP.NET レベルでそれをどうするかについて頭を悩ませています。

私は ASP.NET にかなり慣れていません (MVC で学習しています)。メンバーシップとプロファイル データのプロバイダー モデルについて少し発見しましたが、信じられないほど複雑に思えます (しかし同様に強力です)。私が苦労している特定のことは、データベースへのユーザーの永続性です。これまでのところ、標準のSqlMembershipProvider実装を使用してきましたが、うまく機能しています。ただし、メール検証のためにデータベースに検証コードを保存してチェックしたり (ユーザーのメールアドレスが RPX の結果で未検証としてリストされている場合)、返されたデータを保持したりしたいと考えています。これには、電子メール アドレスなどの認証に不可欠なものもあれば、単なるプロファイル情報 (ユーザーの年齢、性別など) もあります。

ASP.NET データベースには、NHibernate を介してやり取りする他のアプリ固有のテーブルがたくさんあります。ASP.NET のメンバーシップ/プロファイルに関する私の理解では、永続性を処理するため、NHibernate を使用してこれを実行する必要はありません。

私の目標は、サインオン エクスペリエンスを StackOverflow のものと似たものにすることですが、いくつか追加のビット (電子メールの検証など) があります。これを行うには完全なカスタム プロバイダーを構築する必要がありますか? それとも、効果的な方法でデフォルトSqlMembershipProviderを自分の意志に合わせることはできますか?

[このようなアプリケーションのパスワードに関する私の他の質問も参照してください。]

4

1 に答える 1

2

SqlMembershipProvider から継承する新しいプロバイダー クラスを作成し、必要なメソッドをオーバーライドするだけで、過去に同様の作業を行ったことがあります。

基本メソッドの実装を呼び出してほとんどの作業を最初に行い、次に派生クラスで必要な追加ロジックを実行することができます。プロバイダーをゼロから構築するのは大変な作業であり、最後の手段としてのみ使用してください。

aspnet_Membership へのキー参照を使用してデータベースに新しいテーブルを追加できます。次に、派生プロバイダー メソッドから呼び出す独自のストアド プロシージャを追加して、この新しいテーブルに対して必要なことを行います。これは、カスタムのものを分離したままにするため、メンバーシップ スキーマに列を追加するよりも優れています。

何をオーバーライドする必要があるかという点で、SqlMembershipProvider クラスを調査する必要がありますが、説明した内容に基づいて、このアプローチがうまくいくと思います。

于 2009-06-15T04:29:36.950 に答える