默認情況下,當使用@login_required
修飾符時,Django在將未經身份驗證的用戶重定向到登錄頁面時執行302(臨時)重定向。我和一家SEO公司(我自己對這個話題一無所知)一起工作,他堅持認爲301(永久性)重定向對他正在做的工作是必不可少的。關於@login_required修飾符和重定向類型的問題
有沒有辦法強制Django在使用@login_required裝飾器時執行301重定向?
再次感謝。
默認情況下,當使用@login_required
修飾符時,Django在將未經身份驗證的用戶重定向到登錄頁面時執行302(臨時)重定向。我和一家SEO公司(我自己對這個話題一無所知)一起工作,他堅持認爲301(永久性)重定向對他正在做的工作是必不可少的。關於@login_required修飾符和重定向類型的問題
有沒有辦法強制Django在使用@login_required裝飾器時執行301重定向?
再次感謝。
@login_required
修飾器使用redirect_to_login
視圖,該視圖返回一個Django HttpResponseRedirect
對象以將用戶重定向到登錄頁面。如你所說,這個對象表示一個302重定向。還有一個替代重定向對象,HttpResponsePermanentRedirect
,儘管您需要編寫自己的裝飾器來代替它。
當然,編寫自己的裝飾器是可能的。在我看來,這將是不好的做法。不僅僅是因爲它將您的應用程序與驗證模塊的特定實現綁定在一起,而且還因爲在這種情況下302重定向實際上是正確的。
事實是,頁面沒有「永久移動」。相反,用戶只需再次訪問相同的URL之前就需要對自己進行身份驗證。出於這個原因,重定向不是永久的,因爲頁面實際上沒有「移動」。
因此,不能僅僅使用login_required
來改變重定向的類型。你可以編寫你自己的login_required裝飾器來提供301重定向(儘管這裏使用這個是有爭議的)。
301永久重定向在這裏似乎不對。假設你正在保護URL`/ secret-sauce/recipe`。如果我沒有登錄並點擊`/ secret-sauce/recipe`,那麼我應該重定向到登錄頁面。 *但是*該頁面並未永久移動; `/ secret-sauce/recipe`仍然是一個有效的URL(我登錄後應該重定向*返回*)。當頁面移動並在舊URL無效時使用301。 – mipadi 2011-01-27 18:38:50
典型的SEO專家:不知道他在說什麼... :-) – 2011-01-27 19:31:31