51–60 of 80 posts
from here: http://bradwilson.typepad.com/blog/2010/10/mvc3-unobtrusive-...
Speaking with my security hat on: This is a really nice library, but you also do the same validations server side right?
http://www.codebyjeff.com/blog/2012/12/web-form-security-avo...
Nothing to do with sexy xss & the like - just some simple foundation points when setting up your server side procesing
Earlier quoted context omitted.
Client side and server side validations need (should!) not be the same — i'd make serverside validation stricter. Client side is for eliminating honest mistakes not preflighting exploits.
Could you give an off the top of your head example?
1) You can only do a mod 10 check (aka the Luhn algorithm) for client-side credit card validation. Beyond that, you'll need to hit a server to run a CC authorization.
2) In the email check one commenter criticized re: correctly parsing "m@apple.comm", there are practical limits. Syntactically, that's a correct email address. To that you could add content checks such as validating against known TLDs. Then you've got to ensure that your whitelist is correct and that it remains up-to-date as the TLD namespace changes. As for evaluating the registered domain name client-side, ehhhh.. maybe not. At some point you've just got to go do the DNS lookup and send an email to find out if it's going to work.
In general there are classes of problems for which some lightweight validation is practical on the client, but full validation requires extended information or transactions that are im{practical,possible} on the client.
Has anyone had any experience where adding or removing client-side validation has affected conversion? Other comments talked about client-side validation being mainly for UX and user convenience. But I'm wondering if it has a noticeable effect on whether or not people actually submit the form all the way to completion (i.e. no errors). I made a tool that I have server-side form validation. I found that saving the inv…
I can envision that could be easily to push this to Sentry https://getsentry.com/welcome/ using the Sentry Javascript Client
This is neat. A couple of points: 1- Client side validation is easy to circumvent. If you use this you have to make sure it is for UI only and that the real validation happens server side. 2- Using regex for email validation is fraught with issues. Probably the most salient one is that there are a million expressions out there. People run a quick google search, grab one and move on without knowing what they just plug…
2. True, but you have to do something. :) What exactly is wrong with m@apple.comm? That could be valid domain at some point, right? You could filter those out but it's almost a preference sort of question. Does anyone think it would make sense to have "warning" level of validation for email addresses and let the user decide on these sort of examples? Just throwing it out there.
Earlier quoted context omitted.
Great question. I would usually prefer server side validation, and with the nice integration that Rails provides between form errors and validations on the model, I am not sure how I can use this. Does anybody who uses a Rails stack combine both server side and client side validations?
I thought it was standard to have both. Server side validation to keep bad data out and client side validation to provide a nicer UX for the user than a complete page reload and them searching around for what went wrong.
Earlier quoted context omitted.
Could you give an off the top of your head example?
The web is brimming with examples, here are a few: 1) You can only do a mod 10 check (aka the Luhn algorithm) for client-side credit card validation. Beyond that, you'll need to hit a server to run a CC authorization. 2) In the email check one commenter criticized re: correctly parsing "m@apple.comm", there are practical limits. Syntactically, that's a correct email address. To that you could add content checks such…
I don't want to hijack, but I just want to link to the form library I wrote a couple years ago. It has a little less functionality, but it is a little lighter and has no dependencies. It is here: https://github.com/rickharrison/validate.js
This library looks great! I really like the functionality and the html requirement definitions. I don't want to hijack, but I just want to link to the form library I wrote a couple years ago. It has a little less functionality, but it is a little lighter and has no dependencies. It is here: https://github.com/rickharrison/validate.js
This is neat. A couple of points: 1- Client side validation is easy to circumvent. If you use this you have to make sure it is for UI only and that the real validation happens server side. 2- Using regex for email validation is fraught with issues. Probably the most salient one is that there are a million expressions out there. People run a quick google search, grab one and move on without knowing what they just plug…
I don't see a problem with using a regex to validate email, unless you get false negatives. Rejecting anything that could be a valid e-mail address is bad and will cause frustration for someone at some point.
I don't think allowing validly formed e-mail addresses that don't have corresponding accounts (or even domains - consider a web app working in offline mode) is a bad thing, especially when taken with point 1, as surely the point of client side validation is a heads up to the user that the data is wrong, rather than actual validation?