5

MVC4 を使用して最初の超小型 Web アプリを作成しました。これまでのところ、レイアウトを使用して webapp をレイアウトし、いくつかのビュー コントローラーとモデルを追加して登録し、ユーザーがログインできるようにしました。

ユーザーがログイン/登録すると、そのユーザー名をセッションに保存します。セッションからこのプロパティを読み取って、ユーザーがログインしているかどうかを判断します。

それは悪い習慣ですか？RESTful およびステートレス Web アプリケーションについてよく読んでいます。セッションで何も保存してはいけないと感じています。

例えば

@if (string.IsNullOrEmpty(Session["User"] as string))
{
    <dl>
        <dt><a href="/Account/Register">Register</a></dt>
        <dt><a href="/Account/Login">Login</a></dt>
    </dl>
}
else
{
    <dl>
        <dt><a href="/Account/ShowAccount/@Session["User"]">@Session["User"]</a></dt>
        <dt><a href="/Account/Logout">Log out</a></dt>
    </dl>    
}

Q1: これは悪い習慣ですか?

Q2: これは「ハックセーフ」ですか? 現状では、現在のセッションをハッキングして Session["User"] に値を保存してログインをバイパスするのは簡単ですか?

4

1 に答える 1

7

質問に答えるには:

1) 一般に、アプリケーションでセッション状態が必要であり、パフォーマンスとスケーラビリティへの影響を理解している限り、セッション状態を使用することは悪い習慣ではありません。ただし、あなたの場合、保存する必要があるのがユーザーの名前だけである場合、アプリケーションが ASP.Net メンバーシップ プロバイダーを使用している場合、この情報は MVCController の User プロパティで利用できます。基本クラス:

var username = User.Identity.Name

セッション データを保存するには、次の 3 つの方法があります。アプリ プロセスに保存する「InProc」、別のサーバーに出力プロセスを保存する「StateServer」、別のサーバーに保存する「SQLServer」です。 SQL サーバー データベース。どちらを使用する必要があるかは、サーバー ファームを使用しているかどうか、セッションが永続的である必要があるかどうか (つまり、マシンの再起動後も存続する必要があるかどうか)、およびアプリのパフォーマンス要件が何であるか (StateServer と SQLServer は InProc よりもパフォーマンスが低い) によって異なります。詳細はこちら

2) SSL を使用してセッション データを保護する必要があります。SSL (HTTPS) 経由で送信されるデータは完全に暗号化され、ヘッダーが含まれます (したがって Cookie)。セッションハイジャック攻撃を防ぐ方法についての良い議論はここにあります。

于 2012-12-28T17:13:04.220 に答える