3 ms·

There were good suggestions in other comments in this HN post. One of them mentioned that you can continue keeping things as a 1 click solution with the token

by nickjj 5y ago

There were good suggestions in other comments in this HN post. One of them mentioned that you can continue keeping things as a 1 click solution with the token in the URL, but instead of doing the destructive action upon visiting the link -- instead you would get sent to a page with a form where the token is put into a hidden field that gets auto-submit as a POST request with Javascript. This way from your POV it's a 1 click solution. You only waste a second waiting for the redirect and if the user doesn't have Javascript enabled you can <noscript> the field as being an input field which is pre-filled out based on the value from the URL (this can be done server side). Now everyone is happy, unless gmail is going to go as far as auto-following redirects with JS enabled.

wutbrodo 5y ago
Ideally they wouldn't be following redirects _if they're POST requests_, right?
- nickjj 5y ago
  True, that was a bad choice of words but gmail could still load the page, execute the JS which in turn submits the form which is a POST request to your back-end. It's technically not following a redirect but it's doing things beyond just visiting the URL linked in the email due to it executing JS.
  - wutbrodo 5y ago
    Ah interesting, so you're saying that GMail is not likely to be avoiding the POST requests if they're in the JS code? I have a passing, non-professional familiarity with Web practices, so this isn't something I have a great intuition for.
    - nickjj 5y ago
      The basic flow would be: - You GET /reset/abc123 - Your server responds back with a page that has a form - There's a hidden field with the token - Javascript kicks in and on page load executes the form as a POST request - Your server responds to that POST request and does whatever it needs to do All of that is kicked off by gmail visiting /reset/abc123, and now it comes down to whether or not gmail's pre-visiting code will run the JS on the page. If not, then the above workflow fixes this issue, if it does then you're in the same position as avoiding all of this and having a GET /reset/abc123 perform the destructive action.
      - wutbrodo 5y ago
        Right, it's the second part of the fourth bullet that I was asking about. Basically, that it sounds like it isn't feasible for Google to avoid POST requests if they're being submitted from JS.

by nickjj 5y ago

wutbrodo 5y ago

Ideally they wouldn't be following redirects _if they're POST requests_, right?

nickjj 5y ago
True, that was a bad choice of words but gmail could still load the page, execute the JS which in turn submits the form which is a POST request to your back-end. It's technically not following a redirect but it's doing things beyond just visiting the URL linked in the email due to it executing JS.
- wutbrodo 5y ago
  Ah interesting, so you're saying that GMail is not likely to be avoiding the POST requests if they're in the JS code? I have a passing, non-professional familiarity with Web practices, so this isn't something I have a great intuition for.
  - nickjj 5y ago
    The basic flow would be: - You GET /reset/abc123 - Your server responds back with a page that has a form - There's a hidden field with the token - Javascript kicks in and on page load executes the form as a POST request - Your server responds to that POST request and does whatever it needs to do All of that is kicked off by gmail visiting /reset/abc123, and now it comes down to whether or not gmail's pre-visiting code will run the JS on the page. If not, then the above workflow fixes this issue, if it does then you're in the same position as avoiding all of this and having a GET /reset/abc123 perform the destructive action.
    - wutbrodo 5y ago
      Right, it's the second part of the fourth bullet that I was asking about. Basically, that it sounds like it isn't feasible for Google to avoid POST requests if they're being submitted from JS.