4 ms·

In theory, magic links that are only GET and not idempotent are the issue, not the systems/filters hitting them.

• spiffytech 2y ago
  This is one of the reasons to adopt magic codes instead of magic links.
  • tomschlick 2y ago
    Or just have your magic link include a "Confirm Login" button once it loads that sends a POST so automated clients don't cause issues.
    • berkes 2y ago
      ... potentially enriched with JS that hides that button and does a POST for you on documentLoad or such. That way, for a "normal human" it works like they expect, is technically correct, and doesn't trigger on backends fetching the resource. Unless they fetch the resource with some headless chrome or such. Which, unfortunately, is rather necessary these days.
      • zinekeller 2y ago
        > ... potentially enriched with JS that hides that button and does a POST for you on documentLoad or such. Don't do this, most bots now actually load JavaScript.
• zinekeller 2y ago
  Yeah, these filtering appliances/services have many, many misgivings but this one is obviously just following the spec that just happens to be violated by "magic" (not really) links (and not to metion breaking in iOS and other systems which preview them, the futility of trying to ignore robots etc.). You simply know that the designers of the service don't have any real-life testing (and often are snobbish, to boot) if "magic" links are mandatory.
• j45 2y ago
  Magic links/codes are a security compromise on their own. Still, corporate email belongs to the employer. For "magic links", It doesn't solve the problem that the email is intended for a specific individual, for one time use, and the filters are not aware or intelligent enough to do so. In other cases privacy and security of the communication in some cases is being compromised. It does give rise to a bootstrapped solution that delivers links well so I guess that's good.