提取带有中间代理的请求 URI

发布于 2024-11-29 07:51:49 字数 942 浏览 1 评论 0原文

我正在开发一个 Web 应用程序,它需要向用户发送电子邮件,指示他们浏览到属于原始应用程序一部分的某些页面。我当前生成锚点的 href 的代码如下:

String.Format("{0}{1}{2}{3}/{4}",
    Request.Url.Scheme, Uri.SchemeDelimiter, Request.Url.Host, 
    Request.ApplicationPath, path);

目的是它能够工作并链接到正确的站点,无论我是在开发服务器、测试服务器还是生产服务器上运行该站点。然而,有一些缺点,我正在寻求一些帮助来解决。

  1. Request.Url.Scheme 并非在所有情况下都对我们有效。我们的生产服务器需要 https 连接。代理捕获 https 连接,解密请求并将其转发到我们的 Web 服务器。因此,Request.Url.Scheme 将始终显示 http
  2. Request.Url.Host 正在返回我们生产服务器的本地服务器名称;我认为这也与代理问题有关。
  3. 已阅读另一篇建议使用 Request.Headers["host"] 的文章。不确定这是否会遇到同样的问题。

有谁对 HTTP/HTTPS、转发和 ASP.Net 处理此危险代码有更多了解(或者可以为我指出正确的方向)吗?

基本上,如果用户使用 http 从 dev.example.com 的服务器接收电子邮件,则电子邮件中的 Uri 应为 http://dev.example.com/page.aspx。如果用户通过 https 使用生产服务器 secure.example.com(由 Web 代理处理),则链接应为 https://secure.example.com/page.asx

I am developing a web application which needs to send emails to users instructing them to browse to certain pages which are part of the originating application. My current code to generate the anchor's href is as follows:

String.Format("{0}{1}{2}{3}/{4}",
    Request.Url.Scheme, Uri.SchemeDelimiter, Request.Url.Host, 
    Request.ApplicationPath, path);

The aim was that it would work and link to the correct site, regardless of whether I was running the site on the development server, the test server or the production server. However, there are a couple of drawbacks that I'm looking for some help working around.

  1. Request.Url.Scheme will not work in all cases for us. Our production server requires a https connection. The proxy catches the https connection, decrypts the request and forwards it onto our web server. As such, Request.Url.Scheme will always show http
  2. Request.Url.Host is returning the local server name of our production server; I think this is also related to a proxy issue.
  3. Have read another post which suggests using Request.Headers["host"] instead. Not sure if this would suffer from the same issue.

Does anyone with a bit more knowledge of HTTP/HTTPS, forwarding and ASP.Net's handling of this haz teh codez (or can point me in the right direction)?

Basically, if the user receives the email from the server at dev.example.com using http, the Uri in the email should be http://dev.example.com/page.aspx. If the user is using the production server secure.example.com over https (which is handled by a web proxy) the link should be https://secure.example.com/page.asx.

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

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

发布评论

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

评论(1

故乡的云 2024-12-06 07:51:49

根据我在代理中处理单点登录实现的经验,没有转发有关原始请求的任何信息。不幸的是,我们没有找到解决 https 问题的方法。

我不是 100%,但我认为应用程序请求路由包可能允许重写 html 内返回的 url,以便在代理之外工作。例如,如果您将其返回为 http://server.com/page.aspx 它可能会将其重写为 < a href="https://server.com/page.aspx" rel="nofollow">https://server.com/page.aspx。此外,您可以指定将代理服务器上的 http 连接升级为 https 的规则。因此,您将有一个初始的 http 请求,该请求会跳转到 https 请求。

此外,您可能希望您的开发服务器与您的产品服务器尽可能紧密地合作来解决这些问题。

From my experience dealing with an implementation of Single Sign in our Proxy didnt forward any information on about the original request. We found no way around the https issue which was unfortunate.

I am not 100% but I think the Application request Routing package might allow returned urls inside html to be rewritten to work outside the proxy. E.g. if you return it as http://server.com/page.aspx it may rewrite this as https://server.com/page.aspx. Additionally you can specify rules that will upgrade an http connection to https on the proxy server I believe. So you will have an initial http request that jumps to an https one.

Also you probably want your dev server to work as closely as possible to your prod server for these very issues.

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