How can web interface for resetting programmatic access keys protect users from accidentally repeating the action?

Question

There's a web service for data processing. It has two interfaces. One of them is a web interface for users registering, paying with PayPal, etc, it uses regular username plus password authentication. The other is for programmatic access from users' programs and it uses separate access keys which are then stored in users' programs to secure programmatic access.

Users can reset those access keys at any moment using the web interface. Once a user resets the access key his application is useless until he enters the new key into the application. This is a serious problem when the application is on showcase in an application store such as Google Play because the user has to republish his application with the new key.

So resetting the key must at all times be a well-thought action, not something done accidentally.

The more or less good solution is a two-step interface with a confirmation page. User is initially on "settings" page where he sees a "reset key" link. The "reset key" link actually leads to a confirmation page which says something like "This is serious thing, click HERE to confirm, otherwise get out of here", the user is required to follow the link under "HERE" to actually have the key reset. "HERE" link leads to /Profile/DoResetAccessKey URL.

When he clicks "HERE" the following happens:

1. His browser sends a GET /Profile/DoResetAccessKey request
2. The service accepts the request, resets the key, sends the new key via email and then replies with HTTP 200 OK and a webpage saying something like "You're awesome, the key was reset, click THIS to get out of here"
3. User's browser shows the "You're awesome" page and it also shows /Profile/DoResetAccessKey URL in the address bar
4. The user likely navigates elsewhere but it might so happen that he leaves that page open and switches to another tab with lolcats
5. Some time later he has his browser restarted (for any reason) but the open tab is kept by the browser and when he visits that tab again his browser runs another GET /Profile/DoResetAccessKey request and the key is reset again which is usually very, very undesired at that moment.

The proposed improvement has the service reset the key and respond with HTTP 302 Redirect to /Profile/KeyWasReset. The user's browser sees HTTP 302 response and requests another page which is at Profile/KeyWasReset and that page contains "You're awesome" text. This way the browser doesn't store the dangerous URL and accidental reset is prevented.

Is this enough? What else should be done to make this interface protected from accidental key resets?

Answer 1

You're trying to patch around the use of the wrong HTTP method and HTML element. The request to /Profile/DoResetAccessKey should not be a GET, but rather a POST and should use a button element rather than a link (which of course can be styled to look as desired.) Change the method and element and these problems go away.

Having a link with side-effects can lead to unexpected and undesirable outcomes (think crawlers, etc.)

GET requests should only be used for retrieving information, see the Safe Methods section of HTTP 1.1.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

The conventional approach for an operation like this would be a button that POSTs and then since it is a destructive operation, a confirmation dialog of some sort. If the operation is confirmed, the response to the POST can then redirect to a screen with the new key.

Answer 2

Yes it is enough. However, I don't think resetting a key calls for a "You're awesome" compliment.