You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CSRF validation in REST framework works slightly differently to standard Django due to the need to support both session and non-session based authentication to the same views. This means that only authenticated requests require CSRF tokens, and anonymous requests may be sent without CSRF tokens. This behaviour is not suitable for login views, which should always have CSRF validation applied.
This seems like a severe security issue as well as a one-line fix, how come it remains an ignored issue almost a year later? Should I go ahead and add the decorator as a PR?
I did not realize it was the Django admin login only, that does explain why this wasn't resolved earlier. Still, nice to have this in case somebody accidentally exposes the page or some such.
Correct me if I'm wrong or missing something, although:
It seems to me that the LoginView.create is lacking CSRF protection.
Citing the DRF docs regarding SessionAuthentication:
We can see that DRF's GenericViewSet inherits skipping of CSRF checking and the
SessionAuthentication
class skips CSRF checking as the login view's permission class requires the user to be anonymous. (LoginView inherits the SessionAuthentication from here)The
csrf_protect
decorator should probably be set similarly to how Django's LoginView does it.The text was updated successfully, but these errors were encountered: