Applications send out emails to verify user accounts or reset a password. I believe the following is the way it should be and I am asking for references and implementations.
If an application has to send out a link in an email to verify the user's address, according to my view, the link and the application's processing of the link should have the following characteristics:
- The link contains a nonce in the request URI (
http://host/path?nonce
). - On following the link (GET), the user is presented a form, optionally with the nonce.
- User confirms the input (POST).
- The server receives the request and
- checks input parameters,
- performs the change,
- and invalidates the nonce.
This should be correct per HTTP RFC on Safe and Idempotent Methods.
The problem is that this process involves one additional page or user action (item 3), which is considered superfluous (if not useless) by a lot of people. I had problems presenting this approach to peers and customers, so I am asking for input on this from a broader technical group. The only argument I had against skipping the POST step was a possible pre-loading of the link from the browser.
- Are there references on this subject that might better explain the idea and convince even a non-technical person (best practices from journals, blogs, ...)?
- Are there reference sites (preferably popular and with many users) that implement this approach?
- If not, are there documented reasons or equivalent alternatives?
Thank you,
Kariem
Details spared
I have kept the main part short, but to reduce too much discussion around the details which I had intentionally left out, I will add a few assumptions:
- The content of the email is not part of this discussion. The user knows that she has to click the link to perform the action. If the user does not react, nothing will happen, which is also known.
- We do not have to indicate why we are mailing the user, nor the communication policy. We assume that the user expects to receive the email.
- The nonce has an expiration timestamp and is directly associated with the recipients email address to reduce duplicates.
Notes
With OpenID and the like, normal web applications are relieved from implementing standard user account management (password, email ...), but still some customers want 'their own users'
Strangely enough I haven't found a satisfying question nor answer here yet. What I have found so far: