問題タブ [membership-provider]

ポータルのような asp.net Web アプリケーションをゼロから構築したいと考えており、ユーザー管理の標準的な方法として asp.net MembershipProvider を検討していました。SqlMembershipProvider から継承するプロバイダーを作成し、ValidateUser メソッドをオーバーライドします。

入力された資格情報をすべてのアプリケーションに対して検証しようとしていますが、GetAllApplicationsMethod() は aspnet_Applications テーブルからすべてのアプリケーションを取得します (同じテーブルにアプリケーションを挿入するための部分もあります)。

検証が成功した場合、アプリケーション名はメンバーシップ プロバイダーとロール プロバイダーの両方に残されます。それ以外の場合は、匿名ユーザー用に事前定義されたアプリケーションである既定の名前のままになります。

カスタム データベース スキーマを使用してメンバーを格納するカスタム MembershipProvider を作成しましたが、プロバイダーのデプロイ方法がわかりません。私のターゲット サーバーは IIS7 を実行しており、.NET ユーザー プロバイダーを追加するためのダイアログに移動できますが、プロバイダーとクラスを含むアセンブリを選択する代わりに、 MS によって書かれたプロバイダーのカップル。

MembershipProvider クラスが IIS によって検出されるように、特定の場所にアセンブリをドロップする必要がありますか? その場合、.dll はどこに移動する必要がありますか? それ以外の場合、ASP.Net に私の MembershipProvider を使用するように指示するにはどうすればよいですか? 私が見たすべての例は、完全修飾クラス名を参照しているだけで、ファイルをどのようにデプロイする必要があるかについては言及していません。

「カスタム MembershipProvider クラスを実装するには、カスタム Membership クラスも実装する必要がありますか?」という質問があります。ASP.NET でのカスタム メンバーシップ フレームワークの実装について、少し混乱しています。

お見せできるサンプル クラスはありませんが、以前の Web サイトで ASP.NET が使用しているものとは異なるデータベースまたはスキーマを使用していた場合はどうでしょうか。

どうもありがとう！

私が現在取り組んでいるプロジェクトでは、連絡先とアドレス帳ベースのソーシャル マッチングの両方で、ユーザーが複数の電子メール アドレスを提供できるようにすることに関心があります。カスタム メンバーシップ プロバイダーを作成する予定です (aspnet_Membership テーブルは私の好みには重すぎます) が、MembershipProvider システムではアカウントごとに 1 つの電子メール アドレスしか使用できません。

メンバーシップ プロバイダー システムを使用し、ユーザーごとに複数の電子メール アドレスを許可するための最良のアイデアは何ですか? または、MembershipProvider を完全に回避して、独自のシステムを展開する必要がありますか?

ASP.NET メンバーシップ プロバイダー セキュリティ フレームワークを使用したいのですが、SQL Server スキーマを使用したいと考えています。したがって、aspnet_Membership などのテーブルを使用する代わりに、sec.Membership のようなテーブルを使用することをお勧めします。誰かがこれを試して動作させましたか?

標準のASP.Netプロファイルプロバイダーを使用して、すべてのユーザープロファイルを検索する方法を探しています。これは可能ですか、それとも新しいプロファイルプロバイダーを作成する必要がありますか？

シナリオは次のとおりです。

• ユーザー登録
• ユーザーが自分のプロファイルを設定します（好きな色、好きな本、国など）
• その後、ユーザーは、たとえば「緑」の好きな色を持っている他のユーザーを閲覧することができます

データベースに対して直接コーディングすることなく、メンバーシップ/プロファイルプロバイダーを通じてこれをすべて使用したいと思います。

このメンバーシップの件で苦労しています。

わかりました、それで、それは本当に奇妙です。ユーザー登録できます。登録できます、ログインできます。ただし、別のユーザーを登録しようとすると、ユーザーはデータベースに保存されず、ユーザーがログインしようとすると、メンバーシップ資格情報の検証に失敗したイベントが発生します (ユーザーが保存されていないためだと思います)。

これは、新しいユーザーを保存するために使用しているコードです。

ページ上:

CreateUser メソッド:

}}

追加の保存方法は、ユーザーをアプリのデータベースに保存するためのものです。ただし、ユーザーはメンバーシップデータベースにアクセスしていないため、その前に死んでいることがわかります。

私を燃やしている明らかな何かを見た人はいますか？ありがとう！

私は現在、さまざまなユーザーがログインできるサイトを持っており、サブドメインに応じて、さまざまなデータベースからのさまざまなデータが表示されます。この投稿の指示に従って、Initializeメソッド中に動的に設定した「temp」接続文字列を使用するようにSqlMembershipProviderをオーバーライドしています。

http://forums.asp.net/p/997608/2209437.aspx

問題は、SqlMembershipProviderクラスが「静的」に見えることです。複数のユーザーが異なるサブドメインから接続すると、それぞれのデータベースではなく、いずれかのデータベースのユーザーアカウントが表示されることになります。Initializeは、リクエストごとではなく、アプリケーションによって呼び出されているようです。

だからあなたへの私の質問は...これに対する解決策を実装する最も簡単な方法は何でしょうか？

私はこれまでカスタムプロバイダーを作成したことがないので、それがどのように機能するのか、またはどのような制限があるのか​​わかりません。そして、自分で書いた場合、何かを見落とすとセキュリティホールが発生する可能性が常にあります（時間がかかることは言うまでもありません）。何か案は？

更新1：単一のデータベースを持つこともできますが、特定のサブドメイン内のユーザーは、他のサブドメインのユーザーを表示せずに、自分のサブドメイン内のユーザーを追加/編集/削除する機能が必要です。このスキームの下でそれは可能でしょうか？

.NET の認証、メンバーシップ、および/またはプロファイル プロバイダー機能を利用して、.NET Web アプリを会社のエンタープライズ ポータルに統合できるかどうか疑問に思っています。簡単に言うと、ポータルは、ユーザー名、ユーザー プロファイル データ、一部のアクセス権などのフィールドについて、ポータルの「背後」にある任意のアプリケーションにカスタム ヘッダー値を送信します。ポータルに関する問題の 1 つは、Web で利用可能な .NET アプリの多くを活用できないことです。これは、主にユーザーが既に認証されていることを信頼するために、「ポータル対応」になるように設計されていないためです。

カスタム認証プロバイダーを作成して (または何らかの方法でフォーム認証を利用して)、ヘッダー (および IP) を見て、そのユーザーとして自動的に「認証」することは可能でしょうか? 私の考えでは、プロファイル プロバイダー、おそらくメンバーシップ プロバイダーを作成し、何らかの方法で認証を追加することで、Oxite ブログ (私が見つけた .net mvc デモ) のようなクールなコンポーネントをダウンロードし、プロバイダーをカスタム プロバイダーに切り替えて、活用できるようになると考えています。最小限のコード変更で会社のポータルの背後にある。

これは意味がありますか？これらのコンポーネントがパズルにどのように適合するかを理解していない可能性があると感じています.

NHibernate と ASP.Net MVC を使用して新しいプロジェクトを開始しようとしていますが、メンバーシップの問題に直面しています。サードパーティの NHibernate メンバーシップ/ロール プロバイダーを使用するか、独自のプロバイダーを作成するか、プロバイダーをすべてスキップするかを考えています。

Manuel Abadia
の NHCustomProviders - 多くの構成のように思えますが、すべてを web.config に入れたいかどうかはわかりません。
Leo Vildosola の NHibernateProvider - プロジェクト オーナーはもう NHibernate を使用していないため、サポートされていないようです。
Eucalypto - テーブル構造は気に入っていますが、追加の CMS が含まれていることに少し不安があります。
* これらの各プロジェクトは、しばらく触れられていないように見えます。これは、NHibernate の最新バージョンを使用するように更新するだけで余分な作業が必要になる可能性があることを意味します。

これは、何度も解決された問題の 1 つであり、新しい問題の解決に時間を費やし、できればビジネス価値を追加したいと考えています。