Two-step `ActivationView` runs `activate()` on HTTP GET
djramones opened this issue · comments
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, if ActivationError 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'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.
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.
I have the same problem, but its caused by security software. The mail will be checked and the url is scanned for potential risks.
PS: I have also received registration emails where you have to enter a code, so nothing new :)