フィードバック フォームがあり、SSL が必要な ASP MVC 3 Web サイトがあります。
これで、フィードバックの表示と処理を担当する「ContactUs」というコントローラー内に Feedback というアクションが作成されました。
そのアクションで属性を使用する[RequireHttps]と、うまく機能し、URL が「https」に変更されます。しかし、ページ内のすべてのリンクが「https」を指していることに気付きました! この属性がルーティング エンジンにすべてのリンクに同じ属性を適用させたかのように!!!
もちろん、SSL はこの 1 つのアクションにのみ必要であり、残りはすべて通常の http である必要があります。
誰かがこれを解決する方法を教えてもらえますか?
あなたの場合[RequireHttp]、ログイン Cookie を消去すれば、属性は問題ないかもしれません。そうしないと、ネットワーク経由で平文で送信されます。さらなる HTTPS 呼び出しのわずかなコストを回避することは、価値がある以上の作業になる可能性があります。SO はすべて質問のリサイクルに関するものであり、あなたの質問を読んでいる他のユーザーは、ログイン後に HTTP にドロップダウンしても問題ないと考えるかもしれません。
この[RequireHttps]属性をコントローラ タイプまたはアクション メソッドで使用して、「これは SSL 経由でのみアクセスできる」ことを示すことができます。コントローラーまたはアクションへの非 SSL 要求は、SSL バージョンにリダイレクトされるか (HTTP GET の場合)、拒否されます (HTTP POST の場合)。必要に応じて、RequireHttpsAttribute をオーバーライドして、この動作を変更できます。反対のことを行う組み込みの[RequireHttp]属性はありませんが、必要に応じて独自の属性を簡単に作成できます。
Html.ActionLink()プロトコル パラメータを取るオーバーロードもあります。プロトコルとして「http」または「https」を明示的に指定できます。そのようなオーバーロードの 1 つに関するMSDN ドキュメントを次に示します。プロトコルを指定しない場合、またはプロトコル パラメーターを持たないオーバーロードを呼び出す場合は、リンクに現在の要求と同じプロトコルを持たせたいと想定されます。
MVC に属性がない[RequireHttp]のは、あまりメリットがないからです。ほど面白くなく、[RequireHttps]ユーザーが間違ったことをするのを助長します。たとえば、多くの Web サイトは SSL 経由でログインし、ログイン後に HTTP にリダイレクトしますが、これは絶対に間違ったことです。ログイン Cookie は、ユーザー名 + パスワードと同じくらい秘密であり、ネットワーク上で平文で送信されます。さらに、MVC パイプラインが実行される前に、ハンドシェイクを実行してチャネルを保護するための時間 (HTTPS を HTTP よりも遅くする原因の大部分) を既に取っている[RequireHttp]ため、現在の要求または将来の要求がはるかに高速になることはありません。 .
別のカスタム フィルター属性を作成して、http に戻すことができます。この質問から解決策を試してください... アクションレベルで [RequireHttps] を使用して SSL を有効にすると、永久に有効なままになるのはなぜですか?