Hacker News new | ask | show | jobs
by chrismorgan 1101 days ago
> But here’s how you can mess it up:

> • Not having dynamic error validations before someone goes ahead with the payment. It is as simple as using the Luhn algorithm to make some basic checks.

On the other hand, someone that does validation of their own is far more likely to accidentally filter out valid values. This used to be rather common on email addresses. (I’ve been using almost exclusively @chrismorgan.info addresses since about 2010, and had one rejected exactly once, from a regular expression that thought TLDs were only two or three characters long; I was able to use my skills to bypass the check, and the backend accepted it.) Nowadays, people normally just leave client side validation to whatever <input type="email"> does.

So, payment card numbers. I’ve only ever had a 16-digit one, but they can actually be 10–19 characters long, and some people are sure to have hard-coded maxlength=16 and/or minlength=16 (or equivalent JavaScript checks).

There are also those ridiculous things that insist on splitting the card number into multiple fields (four groups of four characters), but that’s generally just painful to work with rather than actually preventing you from using it.

1 comments

> Nowadays, people normally just leave client side validation to whatever <input type="email"> does.

Hah, I wish. SO MANY sites disallow the plus symbol in the email name (e.g. something+else@example.com).

This is a valid email. It should be accepted. Arrrgh.

Because Gmail treats + as an alias, they disable using + specifically so you don't use an alias, either creating multiple accounts or making them collect an easily blockable email ad target.

If you own a Google domain (not for long unfortunetaly, but I hear cloud flare has the same service) you can define *@domain for free and any email sent to the domain ends in the inbox of your choosing. Unlimited adresses.

Catch-all is a pretty standard feature across email providers when you’re using your own domain.

As for +, I have no idea if it’s being blocked on purpose or by accident, but that kind of thing serves a useful purpose for the recipient, not just being able to create multiple accounts easily: automatic labelling. (And if you’re trying to create multiple accounts, plus addressing is an awfully prosaic approach, and there are plenty of other viable techniques, e.g. mail forwarding services, disposable addresses, adding random dots if you’re using Gmail—abc@, a.bc@, a.b.c@ and ab.c@ all go to the same mailbox.)

I was surprised to learn the extent of what is a valid local-part (something+else in your example) of an email. Can have two dots in sequence if the local-part is quoted, and support for non alphanumeric characters like !#$%&'*+-/=?^_`{|}~; if the local-part is quoted, comments with parentheses. And it could be case sensitive.
We have the following validation:

    let form_email: Option::<String> = /* ... */;
    
    match form_email {
        Some(email) if !email.is_empty() => {
            // ... send email with validation link
        },
        _ => {
            // report missing email
        }
    }

If you (can) click the validation link it's a valid email. If not... it's invalid. Saves me the trouble of debugging all the regexes.