В вашем случае атрибут [RequireHttp] может быть в порядке, если вы очистите файл cookie для входа, или вы будете отправлять его в открытом виде по сети. Это может быть больше работы, чем того стоит, чтобы избежать небольших затрат на дальнейшие вызовы HTTPS. SO посвящен повторному использованию вопросов, и другие пользователи, читающие ваш вопрос, могут подумать, что можно перейти к HTTP после входа в систему, хотя обычно это неправильно.
Атрибут [RequireHttps] можно использовать для типа контроллера или метода действия, чтобы сказать, что «доступ к этому можно получить только через SSL». Не-SSL-запросы к контроллеру или действию будут перенаправлены на версию SSL (если HTTP GET) или отклонены (если HTTP POST). Вы можете переопределить RequireHttpsAttribute и изменить это поведение, если хотите. Нет встроенного атрибута [RequireHttp], который делал бы обратное, но вы можете легко создать свой собственный, если хотите.
Существуют также перегрузки Html.ActionLink(), которые принимают параметр протокола; вы можете явно указать "http" или "https" в качестве протокола. Вот документация MSDN по одной из таких перегрузок. Если вы не укажете протокол или вызовете перегрузку, которая не имеет параметра протокола, предполагается, что вы хотите, чтобы ссылка имела тот же протокол, что и текущий запрос.
Причина, по которой у нас нет атрибута [RequireHttp] в MVC, заключается в том, что от него мало пользы. Это не так интересно, как [RequireHttps], и побуждает пользователей делать неправильные вещи. Например, многие веб-сайты входят в систему через SSL и перенаправляют обратно на HTTP после входа в систему, что абсолютно неправильно. Ваш файл cookie для входа в систему так же секретен, как ваше имя пользователя и пароль, и теперь вы отправляете его в открытом виде по сети. Кроме того, вы уже потратили время, чтобы выполнить рукопожатие и защитить канал (что является основной частью того, что делает HTTPS медленнее, чем HTTP) до запуска конвейера MVC, поэтому [RequireHttp] не сильно усложнит текущий запрос или будущие запросы. Быстрее.
person
RickAndMSFT
schedule
16.03.2012
