也許我在想這個問題，但是我想了解在憑證POST後將用戶重定向到登錄頁面的目的。例如，POST操作可以提交用戶的憑證，例如/app/login.php，然後在認證後，登錄應用程序頁面可能會爲用戶加載一個登錄頁面，而無需實際重定向用戶。但是，如果用戶被重定向到新頁面，會發生什麼情況嗎？這是建議，但我沒有找到任何解釋，除了防止用戶可能重新加載頁面，並可能重新提交表單數據。它被推薦爲安全最佳實踐，我可以理解爲什麼可以在這方面做到這一點，但我真的很想回答「......因爲每個人都這樣做」。爲什麼用戶在登錄後重定向到新頁面
非常感謝。
就像一個非常快速的點。當建議是重定向用戶時，它通常使用方法
Post-Redirect-Get方法。因此，用戶通常不會看到「您正在重定向」的信息或類似信息。服務器在響應中發送重定向，瀏覽器採取行動並轉到給定的位置。
簡單例子：
想象一下，你有一個網站：
一個原因是功能分離。因此，登錄頁面專門用於登錄，儀表板頁面用於顯示用戶的帳戶（或類似信息）。
是的，你可以只在登錄頁面中包含儀表板/其他頁面而不用重定向，但是會遇到另一個問題。如果用戶可以使用/ login和/ dashboard訪問他們的儀表板，如果他們爲登錄頁面添加書籤會發生什麼？另外，如果你在一個POST頁面上，那麼如果用戶想刷新頁面，那麼瀏覽器可能會警告他們他們會重新發布。從純粹的可用性角度來看，如果我不得不繼續接受在Facebook上看到我的新聞Feed，這將非常煩人。
每個刷新發布頁面上會記錄用戶回。如果你啓用了審計日誌，那麼你將有一個「登錄」記錄的負載只是因爲用戶想要刷新新聞提要。試想一下，如果您的網站在每個用戶登錄時都做了某些事情（例如發送電子郵件）。只需刷新儀表板頁面就會每次發送一封電子郵件。
另一個原因是，當未經身份驗證的用戶嘗試訪問受限制的頁面時，很多網站將提供重定向URL。登錄後，網站將用戶重定向到他們最初請求的頁面。用於登錄的Post-Redirect-Get使這更容易做到（如果您已經實現了它的一般登錄，那麼它沒有更多的努力來擁有此功能）。
還有其他各種原因，但對我來說最大的一個是形態沒有重新提交。與僅僅登錄無關，但我曾經在我的網站上沒有實現Post-Redirect-Get方法的「測試短信」功能。有人發送了一條測試消息，然後保持按下刷新。在幾分鐘內，我所有的短信信用都用完了。是的，這個人可能剛剛回來並重新提交，但刷新更容易。
非常感謝你們的深思熟慮的迴應。非常感謝。 – jmcdev
我確定有各種其他原因，但我總是在處理登錄後將用戶轉移到新的登錄頁面的原因是爲了確保我的頁面僅包含與其相關的功能。爲什麼要處理登錄的頁面也要關注顯示主頁，這通常需要從一個地方或另一個地方獲取數據？它不應該，功能應該被分離出來。
如果您嘗試將不相關的功能粘貼到應用程序的相同頁面中，您將很快遇到問題，並且很快就會出現難以維護的意大利麪條代碼。
@jmcdev：沒有特別的理由。如果您願意，您可以將用戶留在相同的登錄頁面上。通常，當用戶在登錄頁面中無法看到其他選項時，通常會將用戶重定向到登錄頁面，因爲它們旨在受到保護。
例如，您只需要一個用戶在他準備好結賬時進行身份驗證，以便您可以獲取他的個人信息。
比阻止用戶潛在地重新加載頁面和 潛在地重新提交表單數據。
用戶仍然可以點擊返回按鈕返回並重新提交帖子。唯一的原因是分離頁面的目的。登錄頁面只會將你登錄進去，而沒有別的。
這些答案似乎非常依賴於服務器端的實現。畢竟，您可以從不同的JSP或ASPX中返回用戶的登錄頁面，或者在沒有瀏覽器重定向的情況下響應他們的POST請求。
我相信重定向瀏覽器具有以下優點：
我已經看到這更多的東西，如評論意見，像這樣的網站。我可以重新加載評論頁面，在沒有我的瀏覽器的情況下查看新信息，警告我有關重新發布，以及沒有不明白這意味着要提交其評論副本的用戶。
如果登錄有副作用，那麼你想避免不必要的登錄。
要添加到最後一句中，通常POST請求用於* actions *（登錄是一個示例）。如果你的動作是冪等的，也許重複沒有不好的症狀，但是應用程序的正確行爲是僅當用戶通過UI指示動作時才採取行動。不是當他們試圖刷新頁面。 （+1順便說一句） – grossvogel
非常感謝你所有的深思熟慮的迴應。非常感謝。 – jmcdev
「登錄應用程序頁面可能爲用戶加載着陸頁」 - 這與重定向有何不同？你如何做到這一點沒有一個？ – Oded
我已經寫了一個答案，但也投移動的問題http://webmasters.stackexchange.com - 這是更適合在那裏，我覺得:) –
@Jonathon枕：我覺得這是一個很有（網絡）開發人員的話題，下面有證據表明並非每個Web開發人員都明白這一點。 – grossvogel