模式驗證（作爲登錄頁面iFrame或對象）的要求沒有被重定向到登錄頁面？

Question

這裏可能有幾個問題，但是有一個主要問題......如果我們進行模態驗證，應該實施什麼？讓我試着解釋..

當前環境：
ASP.NET W/.NET 4.0瓦特/窗體身份驗證

我們使用我們的實驗室軟件的客戶必須格外謹慎另一個用戶採取的控制他們的計算機，所以我們不能實現持久超時（我想我上次讀的時候，只要ASP.NET發生什麼事情，你可以繼續延長超時時間，對吧？）。儘管我們在整個實驗室豐富的客戶端應用程序中都使用密碼認證，但我們仍然不希望隨機的人員在某些員工辦公桌旁走路，看看他們正在做什麼並且有些事情會受到影響。所以我一直在思考這個問題很長一段時間，今晚我有了一個頓悟。如果我們要讓登錄頁面在我們的主頁面中的模態div中的iframe（或對象標籤）內的模態對話框中彈出，該怎麼辦？我們如何讓他們的會話永遠到期，但要求他們在會話超時後登錄？如果我們要實施這樣的工作來實現它，還有什麼可以想象的嗎？請注意，如果發生這種情況，我們在軟件中有會話變量，無法重置。我們如何讓他們持續下去，但仍然能夠做到這一點？主要的是我想避免他們被重定向到登錄頁面。這對最終用戶來說很煩人。根據法律規定，他們需要將暫停時間設定爲2分鐘，所以我認爲如果我能使其工作起來，這將非常酷。我們需要注意的其他事情？

Answer 1

我不得不認爲使用asp.net會話，特別是使用forms-auth會很可怕 - 因爲用戶得到2個cookie：會話和授權。想象一下，如果通過身份驗證的用戶A會從經過身份驗證的用戶B竊取會話cookie，會發生什麼情況：它會導致用戶A有權訪問用戶B擁有的所有數據（除非您的代碼檢查auth-cookie中的用戶ID是否擁有會話對象，換句話說，我建議擺脫會話，或者至少爲會話對象添加用戶標識值，並確保從auth-cookie中檢查用戶標識與application_authorize事件中的用戶標識匹配，也許。沒有要求這個信息，但我認爲這是適當的，無論如何。

由於會話和身份驗證cookie相互之間沒有多大關係，就瀏覽器而言，您的目標是保持會話活着，而auth-cookie應該過期，然後，你也許可以通過編寫一段JS（提示：window.setInterval）來解決這個問題，它定期ping一些匿名url（aspx頁面）在您的服務器上（確保您爲這些請求添加一個隨機查詢;例如new Date().getTime()）。 anon aspx頁面需要從會話中讀取（不要寫入！）一些值（或者簡單地檢索會話對象） - 只是爲了保持活動狀態（也許這不是真的必要;請嘗試），但瀏覽器會發送asp.net會話cookie與這些請求，所以你可以保持會議對象這樣永遠活着。

另一方面，您的auth-cookie將會過期。然而，你必須設置web.config設置（認證>表單），以便不使用滑動到期（因爲該模式本質上將auth cookie的有效性/到期延長爲另一個無論超時是幾分鐘）。然後，您可以確定，在cookie過期後（例如20分鐘後），當用戶點擊受保護的鏈接（以及鏈接到受保護頁面的鏈接;非匿名頁面）時，他們將登錄登錄頁。我知道你不想要這個。因此，要解決這個問題，請添加另一個（獨立的）javascript（提示：window.setTimeout([code], 2 * 60 * 1000) // to fire after 2 min since the page-load）以啓動登錄對話框。登錄對話框會通過發佈uid/pwd並讓asp.net驗證它來擴展auth-cookie。另一件事：如果你在頁面上有一個Ajax，你必須考慮將這些js超時重置回0（或者取消然後重新初始化間隔和超時事件）。換句話說，你不能從頁面加載開始測量不活動 - 你必須重置每個用戶動作（單擊或至少在每個Ajax回調）上的不活動計數器。

我在這裏暗示的可能是一個矯枉過正的問題。我可能會嘗試解決這個問題。我會嘗試從圖片中刪除進程內會話，並根據auth-cookie的用戶標識從每個用戶數據每次需要時（或每個請求一次）重新加載它。我不知道爲什麼把會話對象掛在內存中是非常重要的，即使用戶已經註銷了（你怎麼知道他們不會離開一個星期;如果你有會話，那麼保持會話活動會導致你的服務器死機大量的用戶）。也許將會話數據存儲在數據庫或網絡上的其他緩存機制（例如memcached）中，並在每個請求（例如application_authorize）中檢索一次，並將其存儲在request.context中（以免多次從多個位置檢索它）。然後，您的auth-cookie將過期，並且在驗證cookie過期前幾分鐘使用JS彈出登錄對話框（以避免用戶點擊鏈接時用戶登錄頁面出現空隙，如果您關心的話甚至）。

我希望這些想法有所幫助。