Differentiate bad signature from already used signatures

[ppawlak]

Checklist

• I read Contribution Guidelines
• I searched the documentation to ensure that the requested feature is not already implemented and described
• I searched existing issues before opening this one

Is your feature request related to a problem? Please describe.

From what I read in the source code there are no specific exception when a signature had already been used. It just raise a BadSignature:
https://github.com/apragacz/django-rest-registration/blob/master/rest_registration/utils/verification.py#L9
This is because the salt used is not the same after the account had been registered and from the comments this seems by design:
https://github.com/apragacz/django-rest-registration/blob/master/rest_registration/api/views/register.py#L46

The problem is it can lead to a bad user experience. For example, in our setup we have REGISTER_VERIFICATION_AUTO_LOGIN and REGISTER_VERIFICATION_ONE_TIME_USE enabled. If a user follows the verification link on a device, he got registered and logged in. Later on he follows the link on an other device and here we are only able to show a generic error message: "The link is invalid."

Describe the solution you'd like

• We would like a specific exception to be raised like SignatureAlreadyUsed
  OR
• if there was a way to override the verify_registration endpoint we could first check if a user is verified and if not go on with the usual verification

In both cases this will allow us to display a relevant error message to our users like "You are already verified, please log in"

Describe alternatives you've considered

We tried to enable REGISTER_VERIFICATION_AUTO_LOGIN and disable REGISTER_VERIFICATION_ONE_TIME_USE but this leads to this error:

REGISTER_VERIFICATION_AUTO_LOGIN is enabled, but REGISTER_VERIFICATION_ONE_TIME_USE is not enabled. This can allow multiple logins using the verification url.

This is indeed not ideal for security.

[apragacz]

Hi @ppawlak,
thanks for a very detailed feature request.
Unfortunately, this is a big one - the only solution I see at the moment would require to perform additonal changes which would break the backward compatibility.
The solutions I see now:

1. introduce additonal hash of the user state to the verification url: for each case, we would hash specific parts of the user model which should change after the link will be "used". We could compare this hash before verifying the signature, thus having a way to throw SignatureAlreadyUsed.
   I still have no idea how this field (query parameter shared in the verification url) should be named: state, statehash, userhash, userstate ... ? I'm definetely open to ideas here.

2. Introduce additonal profile models which would store the state of the specific link being used.

As I want to leave Django REST Registration modeless option 2 is a no-go at the moment, so I'd go with option 1. If you have another solution please do not hesitate to share it!

As the changes to be introduced outweight the potential benefits at the moment, unfortunately this feature has to go at the botton of the backlog (unless someone else wants to pick it up besides me) and will probably be implemented no earlier than in version 0.7.* (and probably as opt-in, maybe later introduced as opt-out).