[zamadatix]

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]

You misunderstand: the server only cares if your password is valid (boolean), not if it is "almost valid (0.7 strength)".

[zamadatix]

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]

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]

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.

[Dylan16807]

If that's all you want then sure, but that's not what I would call a good password quality meter. It makes no attempt to look for patterns or words or super-common passwords.

[zamadatix]

As noted excuse the basic check functions and use whatever you actually want for check criteria and the amount of work on the server side is still a factor <1 compared to writing that and then a different check on the server. If your password check logic is 50x the size of that though you might be overdoing it, but that's just an opinion. Again I'd argue you should really be validating server side as well anyways, fewer chances to mess something up and accept a weak password.