将 HTTPS 页面上的 URL 重写为 HTTP

发布于 2025-01-03 04:17:00 字数 602 浏览 0 评论 0原文

使用 IIS7 的“绑定”功能,我将网站根目录下的 SSL 证书添加到“https”(端口 443)。然后,我需要特定目录“/secure-directory/”的 SSL 连接。我现在可以通过显式链接到 https 地址来重定向到此目录: https://www.mysite.com /安全目录/。问题是 /secure-directory/ 是我想要使用 SSL 的唯一目录,并且它包含现在维护 https 前缀的导航链接,因此我的“Home”链接现在定向到 https://www.mysite.com 而不是 http: //www.mysite.com

保留 /secure-directory/ 中链接的 http 前缀的理想方法是什么?我有 IIS7 URL 重写模块,因此如果有人可以共享出站规则,我们将不胜感激。否则,我想知道我是否完全以错误的方式处理这个问题,或者是否有比重写规则更好的解决方案。谢谢。

Using the 'bindings' feature of IIS7, I added an SSL certificate at the root of my website to 'https' (port 443). Then, I required an SSL connection for a specific directory, '/secure-directory/'. I can now redirect to this directory by explicitly linking to the https address: https://www.mysite.com/secure-directory/. The problem is that /secure-directory/ is the only directory I want to use SSL, and it contains navigation links which are now maintaining the https prefix, so my 'Home' link now directs to https://www.mysite.com instead of http://www.mysite.com.

What is the ideal way to preserve the http prefix for links in the /secure-directory/? I have the IIS7 URL Rewrite module so if someone can share an outbound rule, that would be much appreciated. Otherwise, I would like to know if I'm going about this entirely the wrong way, or of there is a better solution than a rewrite rule. Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

梓梦 2025-01-10 04:17:00

我正在使用此模块。您可以将 /secure-directory/ 配置为仅通过 https 访问

<secureWebPages>
    <directories>
        <add path="secure-directory" />
    </directories>
</secureWebPages>

I'm using this module. You can configure /secure-directory/ as being access only via https

<secureWebPages>
    <directories>
        <add path="secure-directory" />
    </directories>
</secureWebPages>
粉红×色少女 2025-01-10 04:17:00

我通常使用这样的东西,它一直对我有用。 (虽然不完全确定这是最好的方法)。

您可以在 global.asax 中拥有这样的函数,并可以在 Application_BeginRequest 中调用

private void RedirectToCorrectSSLScheme()
    {
        Uri pageRequest = Request.Url;
        string requestPath = pageRequest.GetLeftPart(UriPartial.Path).ToLower();

        requestPath = Server.UrlDecode(requestPath);
        // PageIsSecure returns if the given page should be secure or not. I 
       //maintain a list of secure pages or 
       //secure directory in an XML config.  
        bool securePage = GetSecurePages().PageIsSecure(requestPath);
        if (pageRequest.Scheme == "https" && !securePage && requestPath.Contains(".aspx"))
        {
            Response.Redirect("http://" + pageRequest.Host + pageRequest.PathAndQuery, true);
        }
        else if (pageRequest.Scheme == "http" && securePage && requestPath.Contains(".aspx"))
        {
            Response.Redirect("https://" + pageRequest.Host + pageRequest.PathAndQuery, true);
        }
    }

I normally use something like this and it has always worked for me. (Not entirely sure this is the best way though).

You can have a function like this in global.asax and can call in Application_BeginRequest

private void RedirectToCorrectSSLScheme()
    {
        Uri pageRequest = Request.Url;
        string requestPath = pageRequest.GetLeftPart(UriPartial.Path).ToLower();

        requestPath = Server.UrlDecode(requestPath);
        // PageIsSecure returns if the given page should be secure or not. I 
       //maintain a list of secure pages or 
       //secure directory in an XML config.  
        bool securePage = GetSecurePages().PageIsSecure(requestPath);
        if (pageRequest.Scheme == "https" && !securePage && requestPath.Contains(".aspx"))
        {
            Response.Redirect("http://" + pageRequest.Host + pageRequest.PathAndQuery, true);
        }
        else if (pageRequest.Scheme == "http" && securePage && requestPath.Contains(".aspx"))
        {
            Response.Redirect("https://" + pageRequest.Host + pageRequest.PathAndQuery, true);
        }
    }
肩上的翅膀 2025-01-10 04:17:00

IMO,这不是 URL 重写问题。但至少在理论上(POC 时间?),您可以编写另一个翻转回非 SSL 的重写规则。然而,重写场景的可扩展性较差,因为每次翻转时都会强制执行两次。这可能是也可能不是问题,具体取决于应用程序的正常使用。

处理此问题的一个简单方法是覆盖菜单控件,以便您可以尊重配置。这意味着菜单对其他实现使用绝对链接(非 SSL 时使用 SSL 的绝对链接,反之亦然)。

如果您需要更多“工业强度”,请考虑将 HTTP 处理程序添加到“管道”并在那里控制 SSL 或非 SSL。我将彻底介绍这一点,这样您就不会最终重新发明轮子(不是这里发明的综合症)并尝试使其成为可重用的抽象。这有点复杂,但当您转向另一个解决方案时,重复起来可能会更简单。我首先会看看是否有人开源了这样的处理程序,因为这并不是一个罕见的问题。

我确信还有其他方法可以看待这个问题。

This is not an URL rewriting problem, IMO. But you can, at least theoretically (POC time?), write another rewrite rule that flips back to non-SSL. The rewrite scenario is not as scalable, however, as it forces two hits every time a person flips. This may or may not be an issue, depending on normal use of the application.

An easy way to handle this is override the menu control(s) so you can respect the configuration. This will mean the menu uses absolute links for the other implementation (absolute for SSL when non-SSL, and vice versa).

If you need something more "industrial strength" consider adding an HTTP handler to the "pipeline" and controlling SSL or non-SSL there. I would walk through this thoroughly so you don't end up reinventing the wheel (not invented here syndrome) and try to make this a reusable abstraction. This is a bit more complex, but can end up simpler to repeat when you move to another solution. I would first look and see if someone open sourced a handler like this, as this is not an uncommon problem.

I am sure there are other ways to look at this.

谁与争疯 2025-01-10 04:17:00

感谢您的回复。我考虑过实施 global.asax 和模块解决方案,但最终最适合我的需求的是出站重写规则。我可能会在以后重新审视这个问题并重新评估我的情况,但现在,这就是我正在使用的(在生产中删除了 1860 端口):(

<rule name="ForceHttpsToHttp" preCondition="ResponseIsHtml1">
    <match filterByTags="A, Img" pattern="^(?!.*javascript).*$" />
        <conditions>
            <add input="{HTTPS}" pattern="ON" />
            <add input="{SERVER_PORT}" pattern="443" />
        </conditions>
    <action type="Rewrite" value="http://{HTTP_HOST}:1860{R:0}" />
</rule>

该模式防止在服务器端单击事件上进行重写,而( .*)会重写并破坏它们)

Thanks for the replies. I considered implementing the global.asax and module solutions, but what ended up working best for my needs was an outbound rewrite rule. I may revisit this at a later date and re-evaluate my situation, but for now, this is what I'm using (with the 1860 port removed for production):

<rule name="ForceHttpsToHttp" preCondition="ResponseIsHtml1">
    <match filterByTags="A, Img" pattern="^(?!.*javascript).*$" />
        <conditions>
            <add input="{HTTPS}" pattern="ON" />
            <add input="{SERVER_PORT}" pattern="443" />
        </conditions>
    <action type="Rewrite" value="http://{HTTP_HOST}:1860{R:0}" />
</rule>

(The pattern prevents rewriting on server-side click events, whereas (.*) would rewrite and break them)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文