web-dev-qa-db-ja.com

ASPNETDBの代わりにカスタムデータベースを使用するASP.NET MVC認証？

メールアドレス（ユーザー名として機能します）とパスワードを含むUserテーブルをプライマリアプリケーションデータベースに既に持っています。デフォルトの認証データベース（ASPNETDB）の代わりに自分のデータベースを使用して認証したいのですが。

質問：

  1. これは悪い考えですか？自分のDBを認証に使用するのは巨大なワームの缶ですか？

  2. これを行うことでどれだけの作業を追加できますか？パスワードをハッシュ化するためのコードと、電子メールとパスワードがDBと一致するかどうかをチェックするクエリがすでにあります。だから、私はゼロから始めることはないでしょう。

  3. ASPNETDBの代わりにデータベースを使用するには、何をする必要がありますか？これがいくつかの簡単な手順で説明できることを願っていますが、そうでない場合は、良い情報源を教えてもらえますか？

更新

ここで3つ目の質問についてもう少し詳細を探しています。独自のMembershipProviderを記述する必要がありますか？ web.configファイルにどのような変更を加える必要がありますか？ [Authorize]独自のソリューションを作成しても、属性は機能しますか？自動生成されたAccountControllerにいくつかの小さな変更を加えて使用できますか、または基本的にアカウントコントローラーを最初から書き直す必要がありますか？

c#asp.netsql-serverasp.net-mvcauthentication
26
devuxer

これは非常に簡単です。MembershipProviderを派生させて、ValidateUserメソッドを実装する必要があります。 post を見てください。 PostgresとMVCでカスタムメンバーシッププロバイダーを使用しています。

16
Davorin

私はあなたの更新された質問に答えます：

独自のMembershipProviderを作成する必要がありますか？

（a）フォーム認証の使用を継続する場合、および（b）ASPNETDBと同じ規則に従わない承認テーブル構造がある場合は、はい。 FormsAuth（以下を参照）が必要ない場合は、MembershipProviderを完全に廃止できますが、お勧めしません。または、ASPNETDBとまったく同じセキュリティテーブルを使用していて、それを別のデータベースにポイントするだけの場合は、既定のプロバイダーを引き続き使用して、その構成を変更するだけです。

Web.configファイルにどのような変更を加える必要がありますか？

独自のカスタムMembershipProviderを使用している場合は、それを<providers>要素の<membership>セクションに登録し、defaultProviderプロパティを変更する必要があります。標準のAspNetSqlProviderを使用している場合は、おそらく接続文字列を変更する必要があるだけです。

独自のソリューションを作成しても、[Authorize]属性は機能しますか？

はい、フォーム認証を使用している場合（AspNetSqlProviderを使用するか、独自のメンバーシッププロバイダーを作成して登録します）。いいえ、フォーム認証を放棄する場合（繰り返しますが、お勧めしません）。

自動生成されたAccountControllerにいくつかの小さな変更を加えて使用できますか、または基本的にアカウントコントローラーを最初から書き直す必要がありますか？

とにかくAccountControllerを書き換える必要があります-製品版アプリにデモコードを残さないでください。ただし、必要な場合-はい、AccountControllerは上記と同じ条件で動作します。

13
Aaronaught

これは私たちのアプリケーションの1つで正確に実行しており、非常に簡単です。入力されたパスワードをハッシュするメカニズムを処理して一致するかどうかを確認し、「IsValidLogon」を呼び出すメソッドのブール値を返すだけの認証サービス（コントローラーから呼び出されます）があります。

私たちの場合、目的は、かなり簡単なタスクの管理をできるだけ軽量にすることでした。

基本的にはASPNETDBを完全に無視しました。ユーザー/パスワードのチェックから有効な応答を受け取った場合、標準のFormsAuthentication.RedirectFromLoginPage（username、createCookieBool）;を呼び出すだけです。

お役に立てば幸いです。

1
reallyJim

同じものを構築するだけなので、1への答えはNOでなければなりません:)標準のasp.netフォーム認証を使用しています。ここでは、FormsAuthentication.RedirectFromLoginPage（username、createCookieBool）メソッドを使用してユーザーをログインさせています。ユーザーに一意のGUID（他の任意のユーザーIDを使用できます）とユーザー名（マスターページに表示するためにHtml.Encode（Page.User.Identity.Name.Split（ "|"。 ToCharArray（））[1]））

ログオンしているユーザーを知る必要がある各コントローラー/メソッドで（User.Identity.Nameを使用して、文字列を分割し、userguidを取得します）。また、[Authorize]属性を使用してこれらのルーチンを装飾します。

1
Michel

  1. いいえ、そして私はほとんどの人がその不気味なメカニズムを信頼していないと思う

  2. 特に、すでにテーブルがあるので、それほど多くはありません。

  3. たとえば、これを見てください： http://forums.asp.net/t/1250726.aspx

1
UpTheCreek

こんにちは、次の簡単な手順に従ってください：

まず、App_Dataフォルダー内の.mdfファイルを削除できます。これらのテーブルは必要ないため、次に、データベースを指すようにweb.configのデフォルトの接続文字列を更新する必要があります。

<connectionStrings>
    <add name=”DefaultConnection” connectionString=”Data Source=SERVER\INSTANCENAME;Initial Catalog=DBNAME;Integrated Security=True” providerName=”System.Data.SqlClient” />
  </connectionStrings>

3番目、Nuget Package Managerを開き、次のコマンドを記述します。

Enable-Migrations
Add-Migration Init
Update-Database

データベースをチェックアウトし、Prefix Aspを持つすべてのASP.NETメンバーシップテーブルが作成されたら、アプリケーションを実行してテストし、サインアップやアプリケーションへのサインインなどのメンバーシップアクションを実行できます。

上記のコマンドを実行した後に作成されたテーブル：

  • AspNetRoles
  • AspNetUserClaims
  • AspNetUserLogins
  • AspNetUserRoles
  • AspNetUsers
  • __MigrationHistory

ソース： https://blogs.msmvps.com/marafa/2014/06/13/how-to-create-asp-net-mvc-authentication-tables-in-an-existing-database/ =

1
Houssam Nasser