[英]Need Suggestions for ASP.Net or IIS Request URL Mangling
環境:
我們有一個使用路由來識別用戶與哪個組織關聯的應用程序。 該URL將采用domain / Organization / OrganizationSubCategory的形式。 用戶遵循其自定義URL並看到登錄頁面。 當他們單擊下一步時,他們將被定向到收集一些人口統計信息的頁面,然后單擊下一步以繼續該應用程序。 當他們這樣做時,將用戶(如果需要)添加到我們數據庫中的組織中。 在初始登錄頁面之后,路由不再適用-將用戶定向到常規的aspx頁面。
該網站吸引了大量進入該應用程序的用戶; 平均每天850個。
問題是少數用戶(少於1%)被添加到錯誤的組織中。
我們正在登錄頁面以及他們提交人口統計頁面時記錄信息。 我們記錄的一件事是Request.RawUrl。 我們開始注意到與一個組織相關聯的用戶被記錄為已請求另一組織的完整正確的URL(包括子類別)。 有時,即使在同一天,也沒有人合法地跟隨錯誤的組織URL。 我們已經有人直接報告說他們只是創建了“子類別”(使用管理應用程序),指示用戶遵循其唯一的URL,但是日志為該用戶顯示了完全不同的URL(我知道這是用戶,因為我正在記錄電子郵件地址和會話ID,因此我可以通過登錄頁面和受眾特征頁面關聯同一用戶的路徑)。 好像IIS有時在創建一個新會話,並只是向該用戶分配一些先前請求的URL。
為了消除某種形式的緩存,我們有:
還有其他建議嗎?
這些是內部用戶嗎? 有代理人注意事項嗎? 但這並不能解釋錯誤的網址。 您是否100%確定為用戶指定了網址A,並且顯示了網址b? 當前是否已分配任何路由模塊? 您確定它不會被另一個模塊中的規則重寫嗎?
這可能是他們的“新用戶”電子郵件(例如ex)包含錯誤網址的應用程序問題嗎?
嗯,我們仍然沒有完全的把握,但是似乎一個組織中的用戶最有可能在Internet上搜索以找到進入系統的URL並對其進行跟蹤。
我無法解釋我在原始帖子中描述的報告。
當我嘗試增強日志記錄以捕獲發布前會話的創建以確認這一點時,begin request事件的日志記錄在我們的QA環境(與生產環境相同)中起作用,但在生產環境中僅工作平緩。 我永遠無法確定原因。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.