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
My workaround for this currently is to simply tell the user in activation_complete.html, if ActivationErrorcode == "already_activated", that their email service could have done this and that they can already log in. At the infra level perhaps folks could also run some bot/crawler countermeasures on the activation URL path, though that's a bit more involved.
The proper fix I think is to run activate() only on POST, like what Django's DeleteView does. GET should only present a form/button, and the user needs to click to confirm activation. This also presents an opportunity for customizations like requiring a captcha solve, though I guess it's also a backwards-incompatible change.
Sorry if this is a duplicate issue, the closest report I found is #104.
The text was updated successfully, but these errors were encountered:
This is a thing I've been thinking about for a while, but any solution has to wait for a major version bump due to being backwards-incompatible, so I'm going to leave this open as a reminder for when the 4.0 release is being planned.
Altering database state on GET requests is frowned upon. (Django, for example, is already deprecating logout via GET.)
Besides being a matter of HTTP spec compliance, there is a known issue with email services preprocessing/crawling links in the email body, causing one-time links to be invalidated before the user gets to click them. For
django-registration
this has been reported in a comment on closed issue #104.My workaround for this currently is to simply tell the user in
activation_complete.html
, ifActivationError
code == "already_activated"
, that their email service could have done this and that they can already log in. At the infra level perhaps folks could also run some bot/crawler countermeasures on the activation URL path, though that's a bit more involved.The proper fix I think is to run
activate()
only on POST, like what Django'sDeleteView
does. GET should only present a form/button, and the user needs to click to confirm activation. This also presents an opportunity for customizations like requiring a captcha solve, though I guess it's also a backwards-incompatible change.Sorry if this is a duplicate issue, the closest report I found is #104.
The text was updated successfully, but these errors were encountered: