Проблема разработки ASP.net, принудительное перенаправление на HTTP, если на HTTPS

Question

На моей главной странице у меня есть функции:

/// <summary>
/// Forces user to use unsecure HTTP connection
/// </summary>
public void FoceUnsecure()
{
    SSLHTTPDirect(false);
}

/// <summary>
/// Forces user to redirect to SSL
/// </summary>
public void ForceSSL()
{
    SSLHTTPDirect(true);
}

/// <summary>
/// Perform the redirect to self
/// </summary>
/// <param name="SSLRequired">True = Force HTTPS, False = Force HTTP</param>
private void SSLHTTPDirect(bool SSLRequired)
{
    if (int.Parse(ConfigurationManager.AppSettings["UseSSL"].ToString()) == 1)
    {
        bool IsOnSSL = HttpContext.Current.Request.Url.Scheme.ToLower() == "https";
        if (SSLRequired && !IsOnSSL)
            Response.Redirect(ConfigurationManager.AppSettings["SecureDomainRoot"] + "" + Request.RawUrl);
        else if (!SSLRequired && IsOnSSL)
            Response.Redirect(ConfigurationManager.AppSettings["MasterDomainRoot"] + "" + Request.RawUrl);
    }
}

На моих страницах, требующих SSL, все работает нормально. Я просто делаю Master.ForceSSL() и он перенаправляет на защищенное соединение, если они находятся по HTTP.

Проблема в том, что я хочу перенаправить все другие страницы в HTTP, если они находятся на HTTPS, без необходимости вручную перелистывать страницы, добавляя вызов функции к ForceUnsecure().

Что бы я ни пытался, я не могу сработать на главной странице, если была вызвана функция ForceSSL () (с использованием флагов и тому подобного). В идеале я хочу что-то вроде

if(!SSLRequired && OnHTTPS){ForceUnsecure()}

Но что бы я ни пытался, главная страница, кажется, выполняет все свои проверки ДО того, как страница контента вызовет ForceSSL(). Поэтому я никогда не узнаю значения, которые задает страница контента.

Answer 1

В ответ на комментарии я превращаю это в ответ:

Я знаю, что это не прямой ответ на ваш вопрос;однако, я чувствую себя достаточно сильно об этом, чтобы попасть на мыльницу, так сказать.

---

Прежде всего, если все, что у вас есть, достаточно чувствительно, чтобы требовать имя пользователя и пароль, то вам не следуетЗащитите своих пользователей, отправив их файлы cookie сеанса в незашифрованном виде путем принудительного отключения SSL после начальной процедуры входа в систему.

Для большинства сайтов количество необходимой дополнительной пропускной способности и / или вычислительной мощности тривиально по сравнению с потерей доверия в случае взлома одной или нескольких учетных записей.Только вы можете решить, стоит ли выключать ssl.

Если вы считаете, что проблемы с производительностью могут перевесить вашу деловую репутацию, используйте стандартные инструменты профилирования для своего приложения, чтобы точно определить, какое влияние это окажет.К ним относятся одноразовые инструменты, такие как YSlow, вплоть до «настоящих» готовых инструментов, подобных тем, которые включены в верхние версии Visual Studio.

Полезные ссылки:
(обсуждение влияния SSL на производительность)
Сколько накладных расходов накладывает SSL?
HTTP против производительности HTTPS

(обсуждается, почему отключение SSL после входа в систему - плохая идея)
http://codebutler.com/firesheep
http://codebutler.com/firesheep-a-week-later-idiot-shepherds
http://codebutler.com/firesheep-three-weeks-later-fallout

(переполнение стека влияет на его безопасность - или его отсутствие) https://meta.stackexchange.com/questions/69171/why-doesnt-the-stack-overflow-team-fix-the-firesheep-style-cookie-theft

Все этоПри этом существуют особые обстоятельства, которые следует учитывать.А именно, каково потенциальное падение в случае, если злоумышленник перехватывает и выдает себя за пользователя на вашем сайте?Если отрицательные аспекты равны нулю или близки к нулю, тогда отключение ssl может быть нормальным.Даже тогда я думал о том, чтобы пойти по этому пути, только если бы цена его не превысила.

Answer 2

Другим аспектом, который до сих пор не рассматривался, является влияние на SEO. Если у вас есть две версии страницы, на которую ссылаются как в формате http, так и в формате https, это может вызвать проблемы с дублированным содержимым в Google. В этом случае вы должны использовать 301 перенаправления на соответствующую версию протокола страницы. Таким образом, если ваша страница входа в систему https://mysite/login, вы должны выполнить перенаправление 301, если вы используете http://mysite/login для версии https. Точно так же, если вы ссылаетесь на домашнюю страницу вашего сайта с безопасного URL-адреса, вам следует использовать незащищенную версию URL-адреса домашней страницы, так как это, скорее всего, будет проиндексировано в поисковых системах. Если это невозможно, то вы можете использовать канонические теги на странице, чтобы сообщить поисковым системам, что предпочтительным форматом страницы является http или https - что будет иметь меньшую эффективность, чем перенаправление 301, но лучше, чем ничего.

См. Эту ссылку для получения дополнительной информации: http://www.mattcutts.com/blog/seo-advice-url-canonicalization/

Answer 3

Возможно, вы захотите взглянуть на класс HttpModule . Они позволяют вам перехватывать запросы, и кто-то сделал что-то в соответствии с тем, что вы пытаетесь сделать.

Answer 4

Вместо того, чтобы делать это в вашем коде, есть модуль, созданный Мэттом Солларсом, который позволяет вам использовать web.config, чтобы указать, какие страницы требуют SSL, а какие нет. Библиотека, статья и код доступны по адресу http://www.codeproject.com/KB/web-security/WebPageSecurity_v2.aspx.