6 ms·

Client side validation is for UX. Server side validation is for security, correctness, etc. They are different features that require different code. Blending

Client side validation is for UX. Server side validation is for security, correctness, etc. They are different features that require different code. Blending the two is asking for bugs and vulnerabilities and unnecessary toil. The real reason that SPAs arose is user analytics.

obpe 4y ago
I have never heard this before. Can you elaborate on the differences? What do you validate on the client side that you don't on the server and vice versa?
- pphysch 4y ago
  Some validations require capabilities that you don't want/need the client to have. There are also validations that can improve UX but aren't meaningful on the server. Like a "password strength meter", or "caps lock is on". Religiously deploying the same validations to client and server can be done, but it misses the point that the former is untrusted and just for UX. And will involve a lot of extra engineering and unnecessary coupling.
  - zamadatix 4y ago
    I'm not sure adding a meter value output to the server side check to use it in both places is really more engineering work. Writing separate checks on the client and server side seems much more likely to create headache and extra work. That said, I could definitely see additional checks being done server side. One example would be actually checking the address database to see if service is available in the entered address. On the other hand, there really isn't any waste here either. I.e. just because you write the validation in server side JS doesn't mean you MUST therefore deploy and use it in the client side JS as well, it just means you never need to worry about writing the same check twice.
    - pphysch 4y ago
      You misunderstand: the server only cares if your password is valid (boolean), not if it is "almost valid (0.7 strength)".
      - zamadatix 4y ago
        I understand the argument I just disagree that having a separate "bool isPasswordValid()" and "float isPasswordValid()" (really probably something that returns what's not valid with the score) function is in any way simpler than a single function used on both sides. Sure, the server may not care about the strength level but if you need to write that calculation for the client side anyways then how are you saving any engineering work by writing a 2nd validation function on the server side instead of just ignoring the extra info in the one that already exists?
        Dylan16807 4y ago
        In this situation code for a good strength meter is going to be an order of magnitude or two more complicated than the boolean validity check. Porting 50x as much code to the server is significantly worse than having two versions or having one shared function and one non-shared function.
        zamadatix 4y ago
        You shouldn't have to port anything. If you mean in the opposite case of two separate languages between client and server side then yeah, of course - by definition you're rewriting everything and there is no way to reuse code. I'm not clear how you're reaching anywhere near 50x complexity though. You're writing something like this on the client side (please excuse the lazy checks): function basicValidatePassword(password) { const minLength = 8; const maxLength = 64; const isValidChars = /^[A-Za-z0-9]+$/; const hasUpperCase = /[A-Z]/; const hasLowerCase = /[a-z]/; const hasSpecialChar = /[\W_]/; const results = {minLength: password.length >= minLength, maxLength: password.length <= maxLength, hasUpper: hasUpperCase.test(password), hasLower: hasLowerCase.test(password), hasSpecial: hasSpecialChar.test(password), hasValidChars: isValidChars.test(password)} results.isValid = Object.values(results).every(item => item); return results; } Then instead of writing another one on the server that only checks the password isn't blank, is less than the maximum, and has valid characters you're just reusing the full 6 check code. That's only twice as many checks, not even twice as many lines, and it's already written. You really should check all 6 again on the server anyways, but that's beside the point. Better still, if you do the reuse as a build step via shared function library file or similar you don't need to copy/paste and it stays in sync automatically. Of particular note there is no UI code here because the meter's UI code is not related to the check function beyond it reads the return value.
  - obpe 4y ago
    I see, I have never implemented those types of validations. We do religiously deploy the same validation on client and server to explicitly avoid the mismatch of client/server validation. Having the client submit "valid" input only to have server reject it is something we have run into. Having only client side validation is something I have never run into. Also, in my opinion things like you suggest you shouldn't do. A password strength metre is only going to give attackers hints at the passwords you have in your system. And I have not see a caps lock on warning in forever. The only password validation we do is the length which is pretty easy to validate on client and server.
    - yawaramin 4y ago
      > A password strength metre is only going to give attackers hints at the passwords you have in your system No, it's not. A password strength meter just shows you the randomness of an input password, it doesn't have anything to do with passwords already in the system.
      - zamadatix 4y ago
        I'd agree with both takes on that it depends on the meter. Ones which truly approximate password entropy work like you say, however, for some reason, the most common use of such meters is to show how many dartboard requirements you've met while ignoring the actual complexity. When this common approach is used you combine "password must be 8 characters or more" with things like "password must have a number, symbol of ${group}, and capital letter" and the average password complexity is actually made worse for a given length due to pigeonholing. In the full picture though, in terms of UI/UX, the meter seems like only a downside. In the dartboard use case it's great because it displays what's still needed in terms users work and think with signalling e.g. "you still need a number, otherwise you're all set". People don't really think in bits of entropy though so ll that really is being signaled by either a meter or a normal failed validation hint is "more complexity and/or length needed". There may be good cases for using a meter while simultaneously implementing good password requirement policy I'm not thinking of though.
        4y ago
- politician 4y ago
  Client side validations predominately drive user experiences. Server side validations predominately enforce business constraints. If you mix the concerns, either your UX suffers (latency) or the data suffers (consistency, correctness).
- nagyf 4y ago
  Everything has to be validated on the server side simply for security reasons. Even if you do all validation on the client side, which prevents the users submitting a form with invalid data, an attacker can work around that. e.g. submitting the form with valid data, but intercepting the request and modifying the values there. Or simply just using curl with malicious/invalid data. You still need the client side validation for UX. The regular users needs to know if they messed up someting in the form. Also it's a much better UX if it's done on the client side, without the need to send an async request for validations.
  - emodendroket 4y ago
    Yeah but that doesn't answer why you can't share validators between the backend and the frontend if both are written in the same language.
    - yawaramin 4y ago
      Because HTML form validation is a built-in native feature of HTML, and it's integrated in the browser: <input type="email" required placeholder="Please enter your email address"> Constantly reinventing the wheel in every app is silly.
      - emodendroket 4y ago
        These validators are rather limited and you’ll end up needing JavaScript for any Web app with anything beyond the simplest requirements.
        yawaramin 4y ago
        They're limited in some ways but they're just about powerful enough to do almost everything you'd need or want to do client-side without making a network request. In my opinion it doesn't make sense to try to fit in tons of complex validation logic in the frontend.
        4y ago
blowski 4y ago
> The real reason that SPAs arose is user analytics. Can you go into that a bit? I don't really understand what you mean.
- pphysch 4y ago
  HTML gives very limited tools for tracking what a (potentially JS-less) user is doing. There are various tricks, like "link shorteners" and "magic pixels" that allow some tracking. But if you want advanced tracking, like tracking what a user is focusing on at a particular instant, you need to wrap the whole document in a lot of JS. SPA frameworks came out of AdTech companies like Meta, and I assure you it wasn't because they had limited engineering resources.
  - adrr 4y ago
    You can do all that with vanilla html. Cursor tracking, scroll tracking. With HTMLX it makes it trivial. React isnt a SPA framework. It’s a component framework. It has no router or even state management. ExtJs is an Mvc framework in JavaScript and can be used to create a full spa app without additional libraries. It also came out in 2007. There is also ember that also predates react and is another mvc framework by the people who did rails.
  - deleted 4y ago
    [deleted]
  - dtagames 4y ago
    This is not correct. SPAs and web components were pioneered by Google with the introduction of Angular. Later, Vue was invented by a previous Google employee who had worked on Angular. Finally, Facebook came up with React (it's a "reaction" to Angular) because they could not be seen using a Google product. If anything, SPAs make metrics harder because they hide the real behavior of the page in local JS/TS code and don't surface as much or any information in the URL. Also, fewer server interactions means fewer opportunities to capture user behavior or affect it at the server level.
    - 4y ago
emodendroket 4y ago
I don't understand why that should be the case. There are a lot of checks that end up needing to be repeated twice with no change in logic (e.g., username length needs to be validated on both ends).
- 8organicbits 4y ago
  Input validation checks are such a small part of the codebase; it feels weird that it would dictate the choice of a server-side programming language. Server-side python is very capable of checking the length of a string, for example. One challenge is that you've got to keep the server-side and client-side validations in sync, so if you'd like to increase the max length of an input, all the checks need to be updated. Ideally, you'd have a single source of truth that both front-end and back-ends are built from. That's easier if they use the same language, but it's not a requirement. You'll also probably want to deploy new back-end code and front-end code at the same time, so just using JS for both sides doesn't magically fix the synchronization concerns. One idea is to write a spec for your input, then all your input validation can compare the actual input against the spec. Stuff like JSON schema can help here if you want to write your own. Or even older: XML schemas. Both front-end and back-end would use the same spec, so the languages you pick would no longer matter. The typical things you'd want to check (length, allowed characters, regex, options, etc.) should work well as a spec. It's also not the only place this type of duplication is seen: you'll often have input validation checks run both in the server-side code and as database constraint checks. Django solves that issue with models, for example. This can be quite efficient: if I have a <select> in my HTML and I want to add an option, I can add the option to my Django model and the server-side rendered HTML will now have the new option (via Django's select widget). No model synchronization needed. As others mention, you may want to write additional validations for the client-side or for the server-side, as the sorts of things you should validate at either end can be different. Those can be written in whichever language you've chosen as you're only going to write those in one place.
  - emodendroket 4y ago
    I don’t disagree that if this is your sole reason for picking a language it is not a great one. But it is a benefit nevertheless. And obviously we can express more complex rules in a full-on programming language.
adrr 4y ago
I don't understand how spa is different than vanilla web app in terms of user analytics? A beacon is a beacon. Whether its img tag with a 1x1 transparent gif or an ajax call. Also validation is usually built on both client and server for the same things. Like if you have a password complexity validation. Its both on UX and the server otherwise it will be a very terrible UX experience.
- ragall 4y ago
  A SPA can track the mouse cursor, as well as stealing form content that was left unsubmitted.
  - adrr 4y ago
    Htmlx has a type ahead attribute that you can add to form elements and send the contents to an endpoint without the user explicit submitting the form.
  - detaro 4y ago
    an MPA can use javascript that does exactly the same.
    - adrr 4y ago
      You don’t even need JavaScript. CSS has Hover attribute and you can use it to fire beacons.
gpapilion 4y ago
I actually tend to think of it to add feature degradation and handle micro service issues. It always seemed better to have the client manage that, and more graceful.
- withinboredom 4y ago
  The number of SPAs that implement their own timeouts when I'm stuck on 2G networks is non-zero and incredibly annoying. The network socket has a timeout function, just because you 'time out' doesn't mean the network timed out, that data is still being transferred and retrying just makes it worse.
tabtab 4y ago
But if you don't blend the two, then you have a DRY violation. Someone should only have a say a field (column) is required in one and only one place, for example. The framework should take care of the details of making sure both the client and the server check. I myself would like to see a data-dictionary-driven app framework. Code annotations on "class models" are hard to read and too static.
- pphysch 4y ago
  DRY has its limitations. Client-server boundary is a good candidate for such a limit.
  - zamnos 4y ago
    that seems like an easy way for validation logic between the two to fall out of sync. Limits want to be enforced on the back end, definitely, but if the frontend also does the same validation the user experience is better, so you want to do some there as well (eg blank username does not need to do the slow round trip to the server). Through the magic of using JavaScript on both ends, the exact same bit of code can, with a bit of work, be used on both the front and the back end, so you can get the best of both worlds.

obpe 4y ago

I have never heard this before. Can you elaborate on the differences? What do you validate on the client side that you don't on the server and vice versa?

pphysch 4y ago
Some validations require capabilities that you don't want/need the client to have. There are also validations that can improve UX but aren't meaningful on the server. Like a "password strength meter", or "caps lock is on". Religiously deploying the same validations to client and server can be done, but it misses the point that the former is untrusted and just for UX. And will involve a lot of extra engineering and unnecessary coupling.
- zamadatix 4y ago
  I'm not sure adding a meter value output to the server side check to use it in both places is really more engineering work. Writing separate checks on the client and server side seems much more likely to create headache and extra work. That said, I could definitely see additional checks being done server side. One example would be actually checking the address database to see if service is available in the entered address. On the other hand, there really isn't any waste here either. I.e. just because you write the validation in server side JS doesn't mean you MUST therefore deploy and use it in the client side JS as well, it just means you never need to worry about writing the same check twice.
  - pphysch 4y ago
    You misunderstand: the server only cares if your password is valid (boolean), not if it is "almost valid (0.7 strength)".
    - zamadatix 4y ago
      I understand the argument I just disagree that having a separate "bool isPasswordValid()" and "float isPasswordValid()" (really probably something that returns what's not valid with the score) function is in any way simpler than a single function used on both sides. Sure, the server may not care about the strength level but if you need to write that calculation for the client side anyways then how are you saving any engineering work by writing a 2nd validation function on the server side instead of just ignoring the extra info in the one that already exists?
      - Dylan16807 4y ago
        In this situation code for a good strength meter is going to be an order of magnitude or two more complicated than the boolean validity check. Porting 50x as much code to the server is significantly worse than having two versions or having one shared function and one non-shared function.
        zamadatix 4y ago
        You shouldn't have to port anything. If you mean in the opposite case of two separate languages between client and server side then yeah, of course - by definition you're rewriting everything and there is no way to reuse code. I'm not clear how you're reaching anywhere near 50x complexity though. You're writing something like this on the client side (please excuse the lazy checks): function basicValidatePassword(password) { const minLength = 8; const maxLength = 64; const isValidChars = /^[A-Za-z0-9]+$/; const hasUpperCase = /[A-Z]/; const hasLowerCase = /[a-z]/; const hasSpecialChar = /[\W_]/; const results = {minLength: password.length >= minLength, maxLength: password.length <= maxLength, hasUpper: hasUpperCase.test(password), hasLower: hasLowerCase.test(password), hasSpecial: hasSpecialChar.test(password), hasValidChars: isValidChars.test(password)} results.isValid = Object.values(results).every(item => item); return results; } Then instead of writing another one on the server that only checks the password isn't blank, is less than the maximum, and has valid characters you're just reusing the full 6 check code. That's only twice as many checks, not even twice as many lines, and it's already written. You really should check all 6 again on the server anyways, but that's beside the point. Better still, if you do the reuse as a build step via shared function library file or similar you don't need to copy/paste and it stays in sync automatically. Of particular note there is no UI code here because the meter's UI code is not related to the check function beyond it reads the return value.
- obpe 4y ago
  I see, I have never implemented those types of validations. We do religiously deploy the same validation on client and server to explicitly avoid the mismatch of client/server validation. Having the client submit "valid" input only to have server reject it is something we have run into. Having only client side validation is something I have never run into. Also, in my opinion things like you suggest you shouldn't do. A password strength metre is only going to give attackers hints at the passwords you have in your system. And I have not see a caps lock on warning in forever. The only password validation we do is the length which is pretty easy to validate on client and server.
  - yawaramin 4y ago
    > A password strength metre is only going to give attackers hints at the passwords you have in your system No, it's not. A password strength meter just shows you the randomness of an input password, it doesn't have anything to do with passwords already in the system.
    - zamadatix 4y ago
      I'd agree with both takes on that it depends on the meter. Ones which truly approximate password entropy work like you say, however, for some reason, the most common use of such meters is to show how many dartboard requirements you've met while ignoring the actual complexity. When this common approach is used you combine "password must be 8 characters or more" with things like "password must have a number, symbol of ${group}, and capital letter" and the average password complexity is actually made worse for a given length due to pigeonholing. In the full picture though, in terms of UI/UX, the meter seems like only a downside. In the dartboard use case it's great because it displays what's still needed in terms users work and think with signalling e.g. "you still need a number, otherwise you're all set". People don't really think in bits of entropy though so ll that really is being signaled by either a meter or a normal failed validation hint is "more complexity and/or length needed". There may be good cases for using a meter while simultaneously implementing good password requirement policy I'm not thinking of though.
      - 4y ago
politician 4y ago
Client side validations predominately drive user experiences. Server side validations predominately enforce business constraints. If you mix the concerns, either your UX suffers (latency) or the data suffers (consistency, correctness).
nagyf 4y ago
Everything has to be validated on the server side simply for security reasons. Even if you do all validation on the client side, which prevents the users submitting a form with invalid data, an attacker can work around that. e.g. submitting the form with valid data, but intercepting the request and modifying the values there. Or simply just using curl with malicious/invalid data. You still need the client side validation for UX. The regular users needs to know if they messed up someting in the form. Also it's a much better UX if it's done on the client side, without the need to send an async request for validations.
- emodendroket 4y ago
  Yeah but that doesn't answer why you can't share validators between the backend and the frontend if both are written in the same language.
  - yawaramin 4y ago
    Because HTML form validation is a built-in native feature of HTML, and it's integrated in the browser: <input type="email" required placeholder="Please enter your email address"> Constantly reinventing the wheel in every app is silly.
    - emodendroket 4y ago
      These validators are rather limited and you’ll end up needing JavaScript for any Web app with anything beyond the simplest requirements.
      - yawaramin 4y ago
        They're limited in some ways but they're just about powerful enough to do almost everything you'd need or want to do client-side without making a network request. In my opinion it doesn't make sense to try to fit in tons of complex validation logic in the frontend.
        4y ago

blowski 4y ago

> The real reason that SPAs arose is user analytics. Can you go into that a bit? I don't really understand what you mean.

pphysch 4y ago
HTML gives very limited tools for tracking what a (potentially JS-less) user is doing. There are various tricks, like "link shorteners" and "magic pixels" that allow some tracking. But if you want advanced tracking, like tracking what a user is focusing on at a particular instant, you need to wrap the whole document in a lot of JS. SPA frameworks came out of AdTech companies like Meta, and I assure you it wasn't because they had limited engineering resources.
- adrr 4y ago
  You can do all that with vanilla html. Cursor tracking, scroll tracking. With HTMLX it makes it trivial. React isnt a SPA framework. It’s a component framework. It has no router or even state management. ExtJs is an Mvc framework in JavaScript and can be used to create a full spa app without additional libraries. It also came out in 2007. There is also ember that also predates react and is another mvc framework by the people who did rails.
- deleted 4y ago
  [deleted]
- dtagames 4y ago
  This is not correct. SPAs and web components were pioneered by Google with the introduction of Angular. Later, Vue was invented by a previous Google employee who had worked on Angular. Finally, Facebook came up with React (it's a "reaction" to Angular) because they could not be seen using a Google product. If anything, SPAs make metrics harder because they hide the real behavior of the page in local JS/TS code and don't surface as much or any information in the URL. Also, fewer server interactions means fewer opportunities to capture user behavior or affect it at the server level.
  - 4y ago

emodendroket 4y ago

I don't understand why that should be the case. There are a lot of checks that end up needing to be repeated twice with no change in logic (e.g., username length needs to be validated on both ends).

8organicbits 4y ago
Input validation checks are such a small part of the codebase; it feels weird that it would dictate the choice of a server-side programming language. Server-side python is very capable of checking the length of a string, for example. One challenge is that you've got to keep the server-side and client-side validations in sync, so if you'd like to increase the max length of an input, all the checks need to be updated. Ideally, you'd have a single source of truth that both front-end and back-ends are built from. That's easier if they use the same language, but it's not a requirement. You'll also probably want to deploy new back-end code and front-end code at the same time, so just using JS for both sides doesn't magically fix the synchronization concerns. One idea is to write a spec for your input, then all your input validation can compare the actual input against the spec. Stuff like JSON schema can help here if you want to write your own. Or even older: XML schemas. Both front-end and back-end would use the same spec, so the languages you pick would no longer matter. The typical things you'd want to check (length, allowed characters, regex, options, etc.) should work well as a spec. It's also not the only place this type of duplication is seen: you'll often have input validation checks run both in the server-side code and as database constraint checks. Django solves that issue with models, for example. This can be quite efficient: if I have a <select> in my HTML and I want to add an option, I can add the option to my Django model and the server-side rendered HTML will now have the new option (via Django's select widget). No model synchronization needed. As others mention, you may want to write additional validations for the client-side or for the server-side, as the sorts of things you should validate at either end can be different. Those can be written in whichever language you've chosen as you're only going to write those in one place.
- emodendroket 4y ago
  I don’t disagree that if this is your sole reason for picking a language it is not a great one. But it is a benefit nevertheless. And obviously we can express more complex rules in a full-on programming language.

adrr 4y ago

I don't understand how spa is different than vanilla web app in terms of user analytics? A beacon is a beacon. Whether its img tag with a 1x1 transparent gif or an ajax call. Also validation is usually built on both client and server for the same things. Like if you have a password complexity validation. Its both on UX and the server otherwise it will be a very terrible UX experience.

ragall 4y ago
A SPA can track the mouse cursor, as well as stealing form content that was left unsubmitted.
- adrr 4y ago
  Htmlx has a type ahead attribute that you can add to form elements and send the contents to an endpoint without the user explicit submitting the form.
- detaro 4y ago
  an MPA can use javascript that does exactly the same.
  - adrr 4y ago
    You don’t even need JavaScript. CSS has Hover attribute and you can use it to fire beacons.

gpapilion 4y ago

I actually tend to think of it to add feature degradation and handle micro service issues. It always seemed better to have the client manage that, and more graceful.

withinboredom 4y ago
The number of SPAs that implement their own timeouts when I'm stuck on 2G networks is non-zero and incredibly annoying. The network socket has a timeout function, just because you 'time out' doesn't mean the network timed out, that data is still being transferred and retrying just makes it worse.

tabtab 4y ago

But if you don't blend the two, then you have a DRY violation. Someone should only have a say a field (column) is required in one and only one place, for example. The framework should take care of the details of making sure both the client and the server check. I myself would like to see a data-dictionary-driven app framework. Code annotations on "class models" are hard to read and too static.

pphysch 4y ago
DRY has its limitations. Client-server boundary is a good candidate for such a limit.
- zamnos 4y ago
  that seems like an easy way for validation logic between the two to fall out of sync. Limits want to be enforced on the back end, definitely, but if the frontend also does the same validation the user experience is better, so you want to do some there as well (eg blank username does not need to do the slow round trip to the server). Through the magic of using JavaScript on both ends, the exact same bit of code can, with a bit of work, be used on both the front and the back end, so you can get the best of both worlds.