Asp.Netのメンバーシップおよびロール機能を使用しているAsp.Net4.0Webアプリケーションに取り組んでいます。
アプリケーションには、ログインページにアクセスできる3つの役割と、アクセスできない1つの役割があります。
それが機能することになっている方法は次のとおりです。
バックエンドユーザー(3つの特権ロールの1つ)がユーザーを作成します。コードでは、これはユーザーの登録ページを使用するのではなく、プログラムで行われます。ユーザーが作成されると、非特権ロールに追加されます。これは、わかりやすくするために、Visitorロールと呼ばれます。
次に、バックエンドユーザーは、https://www.example.com?link =cc82ae24-df47-4dbf-9440-1a6923945cf2の形式で新しいユーザーのリンクを作成します。
リンクにアクセスすると、アプリケーションはクエリ文字列に関連付けられているユーザーを特定し、ユーザー名とパスワード(適切にハッシュ化およびソルト化されている)を取得して、ユーザーをログインさせます。
これは私が元に戻されるところです。これまでのところ、ユーザーの作成は問題なく機能しており、クエリ文字列の値に基づくデータベースクエリがその役割を果たし、関連する情報を返しています。実際のログインを除いて、すべてが順調に流れているようです。プログラムでユーザーをログインさせる明確な方法はないようですが、ユーザーに自分自身をログインさせるというリグマロールを実行する必要がありますが、これは避けるように明示的に言われています。
これが私のコードです。「pers」オブジェクトは、リンクのデフォルトページに到達したときにデータベースから入力されるクラスです。
protected void LogUserIn(string p)
{
SqlConnection conn = UtilityMethods.GetConnection();
Guid par = Guid.Parse(p);
BioProspect pers= new BioProspect(conn);
pers.FillDetailsFromDb(par);
testlable.Text = pers.ToString();
Response.Cookies.Remove(FormsAuthentication.FormsCookieName);
try
{
if (Membership.ValidateUser(pers.Email, pers.Pword))
{
FormsAuthentication.SetAuthCookie(pers.Email, true);
Response.Redirect(Request.Url.Scheme + "://" + Request.Url.Host + "/About.aspx");
testlable.Text = "Logged in!";
}
else
{
throw new Exception("Something went wrong");
}
}
catch (Exception ex)
{
StringBuilder sb = new StringBuilder();
foreach (DictionaryEntry d in ex.Data)
{
sb.Append(d.Key.ToString());
sb.Append(": ");
sb.Append(d.Value.ToString());
sb.Append("\r\n");
}
AMessage(sb.ToString());
}
}
これで、ユーザー名とパスワードの値をデータベーステーブル自体と照合しましたが、すべて正しいです。aspnetテーブルに保存されているパスワードがソルトおよびハッシュされていることを理解しているので、クリアテキストを保持するために作成した一時テーブルの値を確認しています。それはそうです。さらに、上記のコードでは、FormsAuthentication.SetAuthCookieメソッドがユーザー名とパスワードを要求しています。この場合、ユーザー名は電子メールアドレスです。この情報は、デバッグ中に検査した場合にも正しいものです。
私たちが送信しているリンクは、ほとんど1回限りのリンクです。その特定のユーザーに関連する変更が行われるたびに、リンクパラメータの値が変更され、古いリンクは完全に役に立たなくなります。リダイレクト先のページには、その特定のユーザーに直接関連し、他のユーザーには関連しないドキュメントが保持されます。
ただし、「ビジター」には複数のリンクが送信され、さまざまなドキュメントやバージョンのドキュメントが時間の経過とともに追加および変更される可能性があるため、Asp.Netメンバーシップ、プロファイル、およびロールフレームワークのメリットが必要です。
誰かがより良い方法を考えることができますか?私はこれまでこことここで関連するエントリのほとんどを見てきましたが、それらはすべてやや不完全に見えます。
編集
ここで受け入れられた回答から収集した情報を使用して、これを少なくとも部分的に解決したようです
基本的に、問題は、使用するハッシュアルゴリズムを指定する必要があるweb.configメンバーシップセクションでした。現時点では、デフォルトがある場合はそれが何であるかわかりませんが、追加します
<membership hashAlgorithmType="SHA1">
web.configに、少なくとも上記の行が追加された後に作成されたユーザーにログインすることを許可しました。次のステップは、他のユーザーをログインさせることができない理由を理解することです。
ただし、Joeが提案したように、まだThreadAbortExceptionが発生しています。これは、現在、解決に忙しく取り組んでいます。