2011-08-15 51 views
3

我正在開發一個Web應用程序,它需要向用戶發送電子郵件,指示他們瀏覽屬於原始應用程序的某些頁面。我當前的代碼生成錨的href如下:使用代理提取請求URI

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的處理這個haz德codez(或可以指向我在正確的方向)更多的知識?

基本上,如果用戶使用http從dev.example.com的服務器接收到電子郵件,則電子郵件中的Uri應爲http://dev.example.com/page.aspx。如果用戶通過https使用生產服務器secure.example.com(由Web代理處理),則鏈接應爲https://secure.example.com/page.asx

回答

2

從我處理單一登錄實施的經驗來看,我們的代理沒有提供有關原始請求的任何信息。我們沒有找到解決https的問題,這是不幸的。

我不是100%,但我認爲應用程序請求路由包可能允許HTML內的返回的URL重寫爲在代理之外工作。例如。如果您將其作爲返回,則可能會將其重寫爲https://server.com/page.aspx。另外,您可以指定將相關代理服務器上的http連接升級爲https的規則。所以你將有一個初始的http請求跳轉到https。

此外,您可能還希望您的開發人員服務器儘可能與您的prod服務器一起工作,解決這些問題。

+0

感謝您的回答。我將把這個作爲提案提交給我們的管理人員,看看會發生什麼。你對開發和產品儘可能匹配的要求非常好,這是一個問題,我們一直在努力爭取資源來實現目標。 – Anthony

+0

各處都一樣:)當我們轉向更爲結構化的發佈方法時,我們最終確信管理層 - 他們的購買是出於合規性原因。當他們看到有多少次發佈漏洞時,因爲在週期後期發現了環境問題......突然之間變得很重要。 –