> You're not supposed to send off a POST request directly as the page has been loaded to exchange the tokens, but require the user to click on a button to confirm the activity.
Since requiring the user to do anything drastically reduces the go-through rate, the current "standard" is to use either a meta-refresh tag, a HTTP Refresh header [1], setting location.href from JS or a <form> that gets submitted via JavaScript, and a <button> inside a <noscript> for those that don't do JS.
Used to be enough but nowadays content scanners run legitimate chromium embedded and whatnot, which obviously trips over at least the refresh tag/header and the automated Javascript solutions. And that's the problem.
Which again, it's a known problem, existed for many years already and we have a work around for. If you want to do POST requests from URLs sent via email/other communication platforms, you need to make it so the user confirms the activity.
Users who wanted to sign in and have to press a button after loading the page instead of just logging them in won't suddenly not want to login. They have a clear purpose when clicking the link, regardless if they have to click one button afterwards or not.
And besides, if you don't implement it like that, you'll have even more users dropping off because they literally won't be able to sign in at all, no matter how badly they want to.
Won't this shift the meta for malware to a "button" that is 99.9% transparent and overlays the whole page in the hope that someone will accidentally click on it when trying to select text or something? A lot better than 0-click ig but might catch people now and then.
Both Microsoft and Google been doing this in emails for many years. I linked elsewhere a SO question from 7 years ago talking about this issue for gmail, others mentioned some Microsoft stuff there too.
Huh? This has nothing to do with the unsubscribe-header thingy. This is about when you for example provide a URL that contains a token in an email, which you exchange for an authentication token once the user visits the URL. Some people implement that page to automatically do the exchange on page load, instead of waiting for the user to click on a button.
Since requiring the user to do anything drastically reduces the go-through rate, the current "standard" is to use either a meta-refresh tag, a HTTP Refresh header [1], setting location.href from JS or a <form> that gets submitted via JavaScript, and a <button> inside a <noscript> for those that don't do JS.
Used to be enough but nowadays content scanners run legitimate chromium embedded and whatnot, which obviously trips over at least the refresh tag/header and the automated Javascript solutions. And that's the problem.
[1] https://en.wikipedia.org/wiki/Meta_refresh