Hacker News Reader

Comment by sandermvanvliet | Hacker News Reader

I've had to deal with this with e-mail verification links and Auth0. The user clicked the link after getting it in their mailbox but then Auth0 throws up an error page because the e-mail address has already been verified (by Outlook scanning). The problem becomes worse if for some reason the mail ends up in the junk mail folder so the user thinks they've never received the mail but when you check it looks like the e-mail address was verified successfully. That has caused a lot of annoying back and forth trying to figure out what the hell is going on. We ended up adding a custom page to handle e-mail validation so we could handle the situation where the user lands on the page and the address has already been verified. Super annoying.

View on HN

Links like this are stupid regardless of Outlook's behaviour because they require a perfectly reliable client and network and user in a perfectly undisturbed flow. If I can't F5, if I double-click, if my mouse is wonky, my wifi is bad, my power goes out, my computer hangs, my DSL dies just after a click, if I accidentally close the tab.. there are any of a thousand reasons why abusing GET for a one-time-use page or redirect is horribly wrong.

It takes incredible arrogance to continue using them in order to "improve usability" given all the obvious and common cases where they completely destroy usability. The difficulty for a provider to verify they aren't sending you to a phishing or browser 0day page barely scratches the surface.

The only purpose of this link was to verify that the email address is valid. Once it’s verified, you can login.

I have seen services where you have to click a link every time you want to log in

They are called magic links... only thing magic about them is their ability to annoy me

I think they exist to simplify the flow for the subset of users who end up using the Reset Password link each time their session expires.

And I think that subset is much larger than some would expect.

This. You'd be amazed how many users just do a password reset each time to login instead of remembering their login info.

My father has insisted on doing this for over 20 years, but he doesn't know how to do it himself. I expect a password-reset phone call from him every 2 or 3 days and have done since 1998. Just recently he had someone from his bank's IT department call him directly about resetting his password over 500 times.

I'm not sure if he's still doing it but someone put together https://theuserisdrunk.com/ and https://theuserismymom.com/ a few years back... I wonder if you could do something similar here, given the level of absolute predictability that seems to be involved.

I sadly can't put my finger on what's so compelling about this, just that my "oh that person should talk to a UX team lead!" meter just went plink

>They are called magic links... only thing magic about them is their ability to annoy me

I love them and prefer them to creating yet another account with a password.

Me too!

Or "passwordless" login, and I love it. Not many people use password managers and will reuse passwords between websites (I.e. their bank and some random unsecured SaaS product). One-time emailed passwords are an easy way to avoid this problem and have a fairly secure site (mind you, it's only as secure as their email). You can layer 2FA on top of this too.

It's only annoying if the site is constantly timing you out so that every single visit you need to resend. Why not just use secure cookies to remember the user for say a week?

I had a similar case recently where I was getting the magic link in an email on my phone, and needed to copy it into Slack so I could click it on the laptop I wanted to actually log in on

This... was impossible to do, because by long-pressing on iOS to get the Copy prompt, iOS also goes ahead and opens a preview of the link next to it

Haha, I was in a restaurant and you paid through your phone. My browser updated so it closed between the thank you page and the payment click. State was lost so the thank you page was broken. The restaurant didn’t think I paid but my bank account said otherwise (this was a bank transfer via ideal, not credit card). Getting out of there without paying twice was entertaining.

>We ended up adding a custom page to handle e-mail validation so we could handle the situation where the user lands on the page and the address has already been verified.

That's a yikes from me! So I can sign up on your service as anyone with an Outlook account, without verification?

I'd assume the custom page has a random URL and requires entering the email address (requiring a match) or clicking a button. I've seen some account confirmation pages like that.

Facebook has allowed this in the past and someone recently opened an unverified Instagram account with my address.

Discord let someone sign up with my gmail email address, sent an email verification link, and before I saw either the "welcome to Discord" or "please verify your email" links they'd already let the person in as me. I don't know if this is because of google crawling links from mail or some other kind of failure, but I wasn't pleased that Discord would let someone impersonate me.

No it would still require username/password. This was only verifying the email address was correct.

Wow! I think you just figured out an issue I had while working in a previous company using Auth0, where the authentication token would expire before the user had actually gone there (so the user saw an error page when clicking), but on our side it looked like the user went there but dropped off directly after. Had maybe 1% of the users complaining about this, but we never found the root-cause (we moved to our own authentication before we could figure it out). This has to have been why. Thanks for sharing this!

Yw. Took us ages to figure out

HTTP GET requests are supposed to be idempotent, meaning that when you call an URL twice it should not lead to any different result compared to calling it once. This is part of the HTTP standard.

So while I think what Outlook does here is wrong, what these webpages do is simply a bug that should be fixed and shows a lack of understanding of HTTP.

> shows a lack of understanding of HTTP

I think that's a bit too much. Nothing in that suggests that they are breaking anything in the HTTP specification. You're right that GET requests has to be idempotent, but the exchange from the single-time use code you get in email with the API token, is most likely behind a non-GET request (like POST). The HTTP server responds to GET requests with the static assets (HTML/CSS/JS), but then the static assets has JavaScript that calls the POST endpoint for the exchange.

At least that's my guess. I agree it's a bug on their side, and they should fix it. But I think it's more of a UX issue than breaking the protocol.

Agree, the commentor is hung up on their demonstrably superior understanding of HTTP.

We found at least one scanning service to be fetching the URL with the user agent of a browser, and executing JavaScript on the page.

A lot of our user interactions could be simpler, but this sort of behaviour led to many things being put behind a "go" button.

I only wonder how long before scanners and search engines start clicking these buttons to activate content on the page so they can scan/index it.

It's idempotent. Your account won't get un-verified if you open the verification link twice.

Idempotent != side-effect free

It's not though. Loading the page twice creates two different outcomes. Idempotent endpoints can't.

!Idempotent != Reversal of changes

What are the two different outcomes?

1. You open the link once = your account is verified

2. You open the link twice = your account is still verified

???

If it's a magic link for logging in:

1. You open the link once = you're logged in

2. You open the link twice = you're presented with an error that the magic link has already been used.

GET is supposed to be safe as well as idempotent though.

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. (RFC 7231, § 4.2.1)

I wouldn't go around saying others don't understand http. Puts you in a very awkward position when you are wrong. Which, you are. Idempotency and safety are separate concepts related to http. But, you do you. Take the advice however you want.

IMHO it is clearly a wrong assumption on the side of any such sender. A verification link should have clear definite actions for the user receiving it:

- It's me, let me confirm my address

- I never signed up for this heap of diamonds

Whenever I (not even a bot) click or follow a link from my mailbox, by accident or on purpose, I don't expect that to validate an account for anyone else, but me, intentionally, using a password I know.

Honestly that's why I built the email verification page so the user still has to click a button on that page.

I had a customer who had some sort of software that followed the link in the email we sent (no big deal so far), and THEN would follow every link and button on that page.

We had a handy quick decline and accept button on there so they were auto declining things…

I didn’t hate email until I got into web development….

The crawler followed buttons on forms? And sent POST requests? Yikes..

Yup. It was a pain. I have no idea who wrote that and thought it was a good idea…

It was a super basic web form too. Probably the most html markup standard thing we have. Nothing strange about it that could have triggered some sort of strange behavior.

Having decline or accept buttons may not be enough.

How about having a input field asking for the email again to double check?

GET requests are supposed to be idempotent

Reply on news.ycombinator.com