Yes, I decided to ignore that constraint because it doesn't make sense :).
The article suggests performing "server-side membership testing, which is O(1)", but I think this is a bit too much — you can do even easier server-side validation without the list of all valid e-mail addresses, just the information that "@[anything but these two domains] is not an OK target".
> Yes, I decided to ignore that constraint because it doesn't make sense :).
Then the customer won't pay you because you ignored their requirements. They might even sue you because you breached contract.
If the customer asks you for a mound of poo you write them a mountain of poo; you try your damned hardest to make sure that the room smells like poo when they are using the app. If they go home and tell their wife and kids about the giant mound of steaming poo they have been using all day then you have succeeded because they will go back to the one developer who knows how to stick to their senseless requirements.
At the end of the day all the other developers are giving them apps built on principles that only make sense to developers - principles that only really make sense for millions of users and not the few thousand that they have. Principles don't put a house over your head and food on the table - money does.
Heh, yes, the smiley face there encodes something like of ", although of course I know that in the 'real world' people can't just ignore product requirements that don't make sense, and hopefully people will challenge at the design phase insane requirements like 'client-side validation of all possible e-mail addresses' rather than implementing them."
As I understand it, it wasn't the customer who requested client-side email validation; the customer just requested validation against a list of known good addresses (instead of just against a list of known good domains), which is a perfectly reasonable requirement (for reasons given in other posts in this thread). It was the programmer who (insanely) decided to do the email validation client side instead of server side.
Yes, I decided to ignore that constraint because it doesn't make sense :).
It does if you want to give the user instant feedback when they type an address that is in a valid domain but does not actually exist, as Ntrails pointed out. If you think a requirement doesn't make sense, you're supposed to ask the client, not just arbitrarily ignore it.
Which is a much easier problem to solve. I suppose this web server is in the same LAN, or at least whitelisted, so send the email directly to the institution's SMTP server, which is presumably not an open relay.
Checking against the two viable email endings and handling bounces should they occur is reasonable. It wouldn't give the immediate user feedback though in case of spelling error etc.
