3 ms·

Your description isn't a work around, it's the exact same buggy behavior, just implemented in JS, instead of a malware scanner. GET or POST is less important th

Your description isn't a work around, it's the exact same buggy behavior, just implemented in JS, instead of a malware scanner. GET or POST is less important than user action, if your code consumes a token without user action, it doesn't matter if that's server side or client side, GET or POST. If outlook is clicking on links or buttons that generate POST requests, then outlook is broken. If outlook is loading a page, and the page without further interaction is sending a POST, that's just as bad, if not worse than expiring the token on that same GET. I wouldn't call that a work around, would you?

diggan 2y ago
> If outlook is clicking on links or buttons that generate POST requests It isn't though, it's loading URLs it finds in emails, and then runs scripts on those loaded websites, like many "modern" scrapers/crawlers. So if your JavaScript on that URL automatically does POST requests on load, those will happen automatically when their scanner loads the website. But if you instead don't do a POST request on JavaScript load, and do that request when the user presses an actual button on the loaded website, the scanner won't trigger that button automatically (that would be a whole new level of craziness, we're not there (yet)) So yes, it is a workaround. I've implemented this 10s of times already, because it's been an issue for a long time. Edit: The submission article also makes it abundantly clear that this is the very problem they're suffering from: > Microsoft’s security scanning will now not only visit the links you mail out, they will also run the JavaScript on your page, and will also send out any POSTs generated by that JavaScript: The problem is that their JavaScript automatically issues POST request on load, not that Outlook loads and executes JavaScript on the page (although that sucks too, don't get me wrong).
- grayhatter 2y ago
  My point was more, sending a POST request IFF a user interacts isn't a work around, but the expected and desired behavior. It's a bug otherwise. Fixing a bug shouldn't be called a work around. A work around is when you can't fix a bug somewhere else.

diggan 2y ago

> If outlook is clicking on links or buttons that generate POST requests It isn't though, it's loading URLs it finds in emails, and then runs scripts on those loaded websites, like many "modern" scrapers/crawlers. So if your JavaScript on that URL automatically does POST requests on load, those will happen automatically when their scanner loads the website. But if you instead don't do a POST request on JavaScript load, and do that request when the user presses an actual button on the loaded website, the scanner won't trigger that button automatically (that would be a whole new level of craziness, we're not there (yet)) So yes, it is a workaround. I've implemented this 10s of times already, because it's been an issue for a long time. Edit: The submission article also makes it abundantly clear that this is the very problem they're suffering from: > Microsoft’s security scanning will now not only visit the links you mail out, they will also run the JavaScript on your page, and will also send out any POSTs generated by that JavaScript: The problem is that their JavaScript automatically issues POST request on load, not that Outlook loads and executes JavaScript on the page (although that sucks too, don't get me wrong).

grayhatter 2y ago
My point was more, sending a POST request IFF a user interacts isn't a work around, but the expected and desired behavior. It's a bug otherwise. Fixing a bug shouldn't be called a work around. A work around is when you can't fix a bug somewhere else.