5 ms·

Even worse: Client-side validation and server-side validation (and database integrity validation) are all their own domains! I call all of these "domain logic"

by berkes 4y ago

Even worse: Client-side validation and server-side validation (and database integrity validation) are all their own domains! I call all of these "domain logic" or domain validation just to be sure. Yes, they overlap. Sure, you'll need some repetition and maybe, indeed, some DSL or tooling to share some of the overlapping ones across the boundaries. But no! They are not the same. A "this email is already in use" is serverside, (it depends on the case). A "this doesn't look like an email-address, did you mean gmail.com instead of gamil.com" is client side and a "unique-key-constraint: contactemail already used" is even more down. My point is, that the more you sit down (with customers! domain experts!) and talk or think all this through, the less it's a technical problem that has to be solved with DSLs, SPAs, MPAs or "same language for backend and UI". And the more you (I) realize it really often hardly matters. You quite probably don't even need that email-uniqueness validation at all. In any layer. If you just care to speak to the business.

oweiler 4y ago
I always saw client side validation for improving UX and server side validation for improving security.
- carlmr 4y ago
  I once needed to order something in the company's ordering system, but for some reason my manager wasn't set as an approver, by virtue of some glitch, since it had worked a few weeks before, and if you wanted to change approvers you'd need the current approver to approve. But that wasn't set. A classical chicken and egg situation. The button for changing approvers was greyed out, so out of boredom I changed it to active in the client-side code. Lo and behold after clicking the "active" button I got a box for selecting the approver. I could select any user in the company. Even the CEO or myself. I did the right thing and mentioned this to our IT Security department. Since obviously this could be used to order really expensive stuff in the name of the CEO or whoever. They came back to me and told me, the vendor (I'm not sure I want to mention them here because they're happy to sue), knows about this for 3 years and won't fix it.
  - Takennickname 4y ago
    Oracle. Must be.
    - jhartwig 4y ago
      ServiceNow
      - sublinear 4y ago
        Indeed servicenow is the clunkiest and saddest software in use today. Unbelievably terrible. You have to see it to believe it.
siefca 3y ago
Even worse^2, client-side validation may differ from server-side validation and from database-side validation. I cannot imagine client-side checking for a validity of a phone number using freshly downloaded database of current carriers and assignment rules in different countries, I prefer to maintain it server-side, even though it could be possible (thanks to guys from Google and their Libphonenumber). But again, I don't trust the client, so it needs to be re-validated later. Then it will be converted to some native data structure on order to make things faster and unified, a later it will go to a database with its own coercion and validation routines just before application will do a query. This validation trusts the format so it will just make sure the result of conversion is correct. But then the query itself carries a validation aspect: when the number must be unique in some context, it will return error, which will bubble up to user.
dsego 4y ago
I think the main concern for frontend validation was before HTML5 came along with validation attributes. You can easily produce HTML input validation attributes from a Yup schema for example by using its serialization feature (https://github.com/jquense/yup#schemadescribeoptions-resolveoptions-schemadescription https://github.com/jquense/yup#schemadescribeoptions-resolve...). Here is an example from some silly code I wrote a while back testing htmx with deno https://github.com/dsego/ssr-playground/ https://github.com/dsego/ssr-playground/
philderbeast 4y ago
"A "this doesn't look like an email-address" unfortunately this also needs to be done server side, unless your trusting the client to send you information that is what your expecting? client side validation makes for a good user experience, but it does not replace the requirement to validate things server side, and many times you will end up doing the same validations for different reasons.
- berkes 4y ago
  "It depends". If it's merely a hint for the user (did you make a typo?) there's no need to ensure "this is a valid email address". in fact: foo@gamil.com is perfect valid email-address, but quite likely (though not certain!) not what the user meant. I've seen hundreds of email-adres-format-validations in my career, server-side. The most horrible regexps, the most naïve assumptions[1]. But to what end? What -this is a question that a domain expert or business should answer - does it matter if an email is valid? trump@whitehouse.gov is probably valid. As is i@i.pm[2]. What your business- expert quite likely will answer is something in line of "we need to be sure we can send stuff so that the recipient will can/read it", which is a good business constraint, but one that cannot be solved by validating the format of an email. One possible correct "validation" is to send some token to the email, and when that token is then entered, you -the business- can be sure that at least at this point in time, the user can read mail at that address. [1] A recent gig was a Saas where a naïve implementor, years ago, decided that email-addresses always had a TLD of two or three letters: .com or .us and such. Many of their customers now have .shop or somesuch. [2] Many devs don't realize that `foo` is a valid email-adress. That's foo without any @ or whatever. It's a local one, so rather niche and hardly used in practice; but if you decide "I'll just validate using the RFC, you'll be letting through such addresses too!". Another reason not to validate the format of email: it's arbitrary and you'll end up with lots of emails that are formatted correct, but cannot be used anyway.
  - bigtunacan 4y ago
    Just because some places implemented the validation wrong does not mean the validation should not occur. The validation is there to catch user mistakes before sending a validation email and ending up with unusable account creation.
narag 4y ago
A "this doesn't look like an email-address, did you mean... Stop right there. I'm tired of receiving mail from people that gave my email address as if it was their own. Never ever accept an email address unless you can instantly confirm it's valid sending an email and waiting for an answer. If the user can't access their email on the spot, just leave it blank and use another data as key. I wish they included that in GDPR or something.
- berkes 4y ago
  You missed my point, I'm afraid. I meant that it very much depends on the business-case (and hence laws and regulations) what exactly you'll have to verify, and therefore where you verify and validate it. Do you need an address to contact people on? You'll must make sure that the user can read the emails sent to that by you. Do you merely use it as a login-handle? Then it probably only has to be guaranteed unique. Do you need to just store it in some address-book? Then just checking roughly the format is probably enough. "It depends".
  - CRConrad 3y ago
    > Do you need an address to contact people on? You'll must make sure that the user can read the emails sent to that by you. Do you merely use it as a login-handle? Pretty humongous dick move to use someone else's email address as one's own login for some website, wouldn't you agree? What if it's a popular website, and the owner of the address would like to use it for their id; why should anyone else be able to deprive them of that? And thus it's also a dick move from the site operator to allow those dicks to do that. So no, it doesn't depend: Just don't accept untested email addresses for anything.
    - berkes 3y ago
      Again: this depends on the business case. Not all web-applications with a login are open for registration. Not all are public. Not all are "landgrab". Not all have thousands of users or hundreds of registrations a week. Not all are web applications and not all require email validation. Some do. But, like your niche example proves: the business-case and constraints matter. There's no one size fits all.

by berkes 4y ago

oweiler 4y ago

I always saw client side validation for improving UX and server side validation for improving security.

carlmr 4y ago
I once needed to order something in the company's ordering system, but for some reason my manager wasn't set as an approver, by virtue of some glitch, since it had worked a few weeks before, and if you wanted to change approvers you'd need the current approver to approve. But that wasn't set. A classical chicken and egg situation. The button for changing approvers was greyed out, so out of boredom I changed it to active in the client-side code. Lo and behold after clicking the "active" button I got a box for selecting the approver. I could select any user in the company. Even the CEO or myself. I did the right thing and mentioned this to our IT Security department. Since obviously this could be used to order really expensive stuff in the name of the CEO or whoever. They came back to me and told me, the vendor (I'm not sure I want to mention them here because they're happy to sue), knows about this for 3 years and won't fix it.
- Takennickname 4y ago
  Oracle. Must be.
  - jhartwig 4y ago
    ServiceNow
    - sublinear 4y ago
      Indeed servicenow is the clunkiest and saddest software in use today. Unbelievably terrible. You have to see it to believe it.

siefca 3y ago

Even worse^2, client-side validation may differ from server-side validation and from database-side validation. I cannot imagine client-side checking for a validity of a phone number using freshly downloaded database of current carriers and assignment rules in different countries, I prefer to maintain it server-side, even though it could be possible (thanks to guys from Google and their Libphonenumber). But again, I don't trust the client, so it needs to be re-validated later. Then it will be converted to some native data structure on order to make things faster and unified, a later it will go to a database with its own coercion and validation routines just before application will do a query. This validation trusts the format so it will just make sure the result of conversion is correct. But then the query itself carries a validation aspect: when the number must be unique in some context, it will return error, which will bubble up to user.

dsego 4y ago

I think the main concern for frontend validation was before HTML5 came along with validation attributes. You can easily produce HTML input validation attributes from a Yup schema for example by using its serialization feature (https://github.com/jquense/yup#schemadescribeoptions-resolveoptions-schemadescription https://github.com/jquense/yup#schemadescribeoptions-resolve...). Here is an example from some silly code I wrote a while back testing htmx with deno https://github.com/dsego/ssr-playground/ https://github.com/dsego/ssr-playground/

philderbeast 4y ago

"A "this doesn't look like an email-address" unfortunately this also needs to be done server side, unless your trusting the client to send you information that is what your expecting? client side validation makes for a good user experience, but it does not replace the requirement to validate things server side, and many times you will end up doing the same validations for different reasons.

berkes 4y ago
"It depends". If it's merely a hint for the user (did you make a typo?) there's no need to ensure "this is a valid email address". in fact: foo@gamil.com is perfect valid email-address, but quite likely (though not certain!) not what the user meant. I've seen hundreds of email-adres-format-validations in my career, server-side. The most horrible regexps, the most naïve assumptions[1]. But to what end? What -this is a question that a domain expert or business should answer - does it matter if an email is valid? trump@whitehouse.gov is probably valid. As is i@i.pm[2]. What your business- expert quite likely will answer is something in line of "we need to be sure we can send stuff so that the recipient will can/read it", which is a good business constraint, but one that cannot be solved by validating the format of an email. One possible correct "validation" is to send some token to the email, and when that token is then entered, you -the business- can be sure that at least at this point in time, the user can read mail at that address. [1] A recent gig was a Saas where a naïve implementor, years ago, decided that email-addresses always had a TLD of two or three letters: .com or .us and such. Many of their customers now have .shop or somesuch. [2] Many devs don't realize that `foo` is a valid email-adress. That's foo without any @ or whatever. It's a local one, so rather niche and hardly used in practice; but if you decide "I'll just validate using the RFC, you'll be letting through such addresses too!". Another reason not to validate the format of email: it's arbitrary and you'll end up with lots of emails that are formatted correct, but cannot be used anyway.
- bigtunacan 4y ago
  Just because some places implemented the validation wrong does not mean the validation should not occur. The validation is there to catch user mistakes before sending a validation email and ending up with unusable account creation.

narag 4y ago

A "this doesn't look like an email-address, did you mean... Stop right there. I'm tired of receiving mail from people that gave my email address as if it was their own. Never ever accept an email address unless you can instantly confirm it's valid sending an email and waiting for an answer. If the user can't access their email on the spot, just leave it blank and use another data as key. I wish they included that in GDPR or something.

berkes 4y ago
You missed my point, I'm afraid. I meant that it very much depends on the business-case (and hence laws and regulations) what exactly you'll have to verify, and therefore where you verify and validate it. Do you need an address to contact people on? You'll must make sure that the user can read the emails sent to that by you. Do you merely use it as a login-handle? Then it probably only has to be guaranteed unique. Do you need to just store it in some address-book? Then just checking roughly the format is probably enough. "It depends".
- CRConrad 3y ago
  > Do you need an address to contact people on? You'll must make sure that the user can read the emails sent to that by you. Do you merely use it as a login-handle? Pretty humongous dick move to use someone else's email address as one's own login for some website, wouldn't you agree? What if it's a popular website, and the owner of the address would like to use it for their id; why should anyone else be able to deprive them of that? And thus it's also a dick move from the site operator to allow those dicks to do that. So no, it doesn't depend: Just don't accept untested email addresses for anything.
  - berkes 3y ago
    Again: this depends on the business case. Not all web-applications with a login are open for registration. Not all are public. Not all are "landgrab". Not all have thousands of users or hundreds of registrations a week. Not all are web applications and not all require email validation. Some do. But, like your niche example proves: the business-case and constraints matter. There's no one size fits all.