我想爲傳入服務器的所有請求構建一個「審計線索」，但它需要針對每個用戶，每個網頁特定。爲每個網頁的用戶記錄所有請求
比如我想是這樣的：
在初始視圖渲染我將存儲（餅乾/頁變量/別的東西）一個唯一的ID稱用戶瀏覽到/myapp.com/dashboard/ 1234。 - 也許在layout.cshtml中。
然後，應用程序觸發X個GET/POST請求到服務器，每個請求都具有最初綁定到呈現視圖的相同唯一標識。
這使我可以綁定頁面的所有請求並加起來服務器執行時間。
我嘗試使用路徑特定的Cookie，但這不會工作我意識到，因爲用戶可以有許多標籤打開相同的網址。此外，用戶還可以一次在應用程序的許多區域工作。他們可以打開1到10個以上的選項卡。其中每一個都應該有它自己獨特的ID和在該頁面上發生的所有呼叫的「審計線索」。
這是一個現有的應用程序，因此修改每個GET/POST以傳入唯一標識超出範圍。只是希望我錯過了可能會照顧到這一點的事情。
謝謝！
如果我正確地理解了你，你有一個單一的頁面加載，然後爲圖像和其他資源或AJAX請求附加請求，你想要綁定和追蹤與該初始頁面加載。
這裏你會遇到的主要問題是，根據HTTP的工作方式，每個請求都被當作自己的東西來處理，而不被視爲更大整體的一部分。 Web瀏覽器使它看起來都是無縫的，但所有的Web服務器正在做的只是響應一堆（據其知道）各種不同事物的無關請求。要將它們全部作爲一個單元進行跟蹤，您需要將一些唯一ID附加到請求本身（對於GET，這可以作爲URI路徑或查詢字符串的一部分），也可以依靠Session來在請求之間引入狀態。但是，當所有請求都可以綁定到單個初始請求時，會話狀態僅適用於此場景。一旦用戶開始一次處理多個不同的頁面，就沒有理由辨別出哪個請求屬於哪個請求，並且您又回到了同一條船上。
換句話說，你的唯一真正的選擇是與請求一起發送的東西，這意味着做這樣的事情：
<link rel="stylesheet" type="text/css" href="/path/to/[email protected]" />
然後，你可以有一個動作過濾器，在查詢查找origin任何請求的字符串，並將其綁定到該特定頁面的日誌記錄。
值得注意的是，默認情況下，IIS將直接處理所有靜態資源請求，而不涉及ASP.NET。如果你確實想跟蹤靜態資源的請求，你必須通過ASP.NET傳遞它們，這會很痛苦。如果你只想跟蹤AJAX請求，那就簡單多了，而且大多數情況下不需要特別的東西。
所有這一切說，如果唯一的目的是跟蹤頁面加載時間，有更好更簡單的方法來做到這一點。你可以安裝Glimpse。您可以使用瀏覽器的開發人員控制檯。您可以使用Google Analytics等內容。對於頁面加載統計信息，所有這些都比你在這裏下載的路徑要好得多。
寫一個ActionFilter來做到這一點。這方面有
http://rion.io/2013/04/15/creating-advanced-audit-trails-using-actionfilters-in-asp-net-mvc/
http://blog.ploeh.dk/2014/06/13/passive-attributes/
很多例子我個人很喜歡馬克·西曼的例子更多，因爲它明確規定了對於屬性和過濾器關注一個很好的分離。
我已經在使用過濾器來處理日誌記錄（不是我需要幫助的）。 這仍然不能唯一標識來自/myapp.com/dashboard1/123與/myapp.com/otherthings/123的請求。我需要知道頁面+用戶特定的請求跟蹤。在包含用戶信息的服務器上獲取原理沒有問題。 – blatantlyObvious
爲什麼不工作filterContext.HttpContext.Request.Url或filterContext.HttpContext.Request.RawUrl來獲取url – Fran
試過。它適用於POST，但是在GET Request.Url，RawUrl，AbsoluteUri與當前網址欄中的內容不匹配。他們是行動發生的烏里。唯一匹配的是UrlReferrer，但這並不總是我的可靠來源，因爲我們實際上可能會重定向它們（並且在這種情況下會是一個新視圖，從而啓動一個全新的審計試用版）...此外，這不會如果他們有兩個相同的頁面打開工作，因爲它會顯示相同的網址。 – blatantlyObvious
我覺得這是不可能的，沒有修改每個請求附加一個ID傳回。這是我最初想到的，也不想走這條路。只是想也許，也許，有人解決了這個問題:)謝謝 – blatantlyObvious