0

We have a HTTP GET URL which triggers an email. The URL was sent out in a mailing so it is not possible without further consequences to make it a POST URL.

Currently we face the problem that a user is getting such confirmation mails multiple times a day.

My theory is, that the URL is opened in some tab or is being pre-fetched every time the user opens the browser and so triggers the email.

Is there a possibility to "tell" the browser to not load such an URL automatically ?

Or is the only option to make a confirmation page which requires an additional button click?

User agent is ""Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0"

EDIT: The URL is basically public, but it has a user identifying token in it. I know that browsers ask for confirmation to rePOST data, but I they do not ask for such confirmation on GET URLs. I am aware of the fact, the GET URLs should not cause any more actions but in this specific case we have the URL in an button in an email and would like to directly cause an action.

So my question is more like: "can I tell the browser that this URL is dangerous to call twice, i.e. to behave like it was a POST URL, for example by a specific header"

Alex
  • 32,506
  • 16
  • 106
  • 171

1 Answers1

1

Browsers don't usually allow such code snippet executions from a specific domain as these are considered security loopholes from the end user browser's perspective. Your theory seems true to me as when I disconnect and reconnect my laptop to the internet, usually all chrome browser's tabs get refreshed on just clicking them. You could grab the user machine's IP from the load balancer OR from the web/app server logs to confirm it once.

But even if you find a solution for 'telling' the browser, I am sure NOT all browsers would allow. Having a confirmation page and/or making it a POST call would certainly make it robust (considering that search engines also might occasionally call publically exposed GET URLs, for refreshing their indices).

GET, HEAD, OPTIONS and TRACE methods are defined as safe, meaning they are only intended for retrieving data. This makes them idempotent as well since multiple, identical requests will behave the same, but here things seem a bit different with GET :D

If this can't change, another approach could be limiting the number of emails for a specific user within a specific time interval, all done from the server side.

See a related discussion here: Can I disable browser refresh in my webapp?

gargkshitiz
  • 2,130
  • 17
  • 19
  • I did not ask for a hack :-D I will clarify my question a bit – Alex May 16 '18 at 13:43
  • Oh, that's the first word that came in my mind. I have edited my post :) – gargkshitiz May 16 '18 at 14:26
  • The funny part is that they are idempotent as they all trigger the same mail.. Which is not intended. Not sending always an email would make them less idempotent in theory as I understand it – Alex May 16 '18 at 16:19
  • My 'another approach' is just a hack :D and thank you for accepting the post as an answer. If we consider the email queue as a server side resource, then its state is changing, isn't it? – gargkshitiz May 16 '18 at 16:34
  • true. Just one other thing: aren't most of the email-verification links violating this principle ? You click a (GET) link and the email-verification / opt in status changes. – Alex May 16 '18 at 19:01
  • 1
    It's old but have a look: https://www.artima.com/weblogs/viewpost.jsp?thread=152805. Another read: https://stackoverflow.com/questions/39690159/whats-the-rest-way-to-verify-an-email – gargkshitiz May 17 '18 at 07:01