頁面刷新時怎么進行csrf token判斷？4）將{%CSRF添加到表單中Django本機支持簡單易用的跨站點請求偽造保護。在提交啟用了CSRF保護的post表單時，必須在上述示例中使用CSRF uu

頁面刷新時怎么進行csrf token判斷？

4）將{%CSRF添加到表單中Django本機支持簡單易用的跨站點請求偽造保護。在提交啟用了CSRF保護的post表單時，必須在上述示例中使用CSRF uu2; Token template label。第一步：當Django第一次響應客戶機的請求時，后端隨機生成一個令牌值，并將令牌保存在session狀態(tài)。同時，后端將令牌放入cookie中并將其提供給前端頁面。第2步：下一次前端需要發(fā)起請求（如發(fā)布）時，令牌值將添加到請求數據或標頭信息中，并發(fā)送到前端頁后端；cookies:{csrftoken:xxxxx}步驟3：后端驗證前端請求攜帶的令牌與會話中的令牌是否一致；

假設我拿到了別的用戶的淘寶網站的cookie，我放到自己的http請求里，我就可以冒充這個用戶嗎？

，從理論上講，如果你得到了cookie，你就可以模仿用戶。根據以下具體分析：

此“身份密碼”由服務器生成并放置在客戶端瀏覽器的cookie中。服務器將有一個與之對應的會話，會話ID也存儲在cookie中。

如上所述，服務器的會話ID存儲在客戶端的cookie中，以便其他用戶在cookie中獲得會話ID后，可以模擬原始用戶啟動請求。

這似乎不合理

！但是，這是cookies和會話的機制。我們說過當cookie被禁用后，session可能無法正常工作，但是我們可以通過get將sessionid傳遞給服務器，因此如果sessionid以明文形式傳輸，則存在安全風險。

由于cookie存儲在客戶機中并且不安全，因此當我們將用戶數據存儲在cookie中時，我們將對其進行加密。例如，它將驗證用戶的IP、終端身份等，即使其他用戶偽造Cookie，也無法驗證。