It has been long time since we have been validating our forms using JavaScript. I am sure this must be the case with most other developers.
Question:
What if the user (or probably a bad guy) disables JavaScript?
You are lost!
Is JavaScript validation worth of it?
Should we ever use it now?
Are there any solutions to this?
Correct me if I am wrong.
Is JavaScript validation worth of it?
Yes, as it provides a better user experience and preserves bandwidth.
Should we ever use it now?
Yes, for the aforementioned reasons.
Are there any solutions to this?
Yes, use server-side validation as well.
What if the user (or probably a bad guy) disables javascript?
As said before: Simply do not rely on the client. Never do so. Check everything on the server again.
Should we ever use it now?
Yes - so the user immediately sees what's wrong. Otherwise he had to post back the data first which may take a while. By the way you reduce traffic to your server.
It's simply more inuitive.
//EDIT:
BTW: The ASP.NET ValidationRules contain both client-side and server validation as far as I know.
Javascript validation is good because it provides a better user experience.
You should however never rely on it and should validate on the server regardless.
If you're looking to save time, go with server-side only. If you want better performance and user experience, add client-side validation afterward. Never rely on client-side validation, for the reasons you state. All critical validation should occur on the server ... even if duplicated on the client.
JavaScript improves user interaction for your product or service. Users interaction (user input and machine response or vice versa) is a vital characteristic of our applications. As we all experienced, products are getting more interactive ever than before. And this interaction part can (only) be crafted in JavaScript (ActionScript for Flash Player). We would all agree with this - there is always a calculated amount of work that can be transited to the client side (machine) to avoid calls without bothering them to send to the server(s). There are many many applications which are heavily dependent on client-script scripting. And if they found you do not allow required scripting they asked for it leaving a message in noscript tag. But I think everyone wants to have it enabled as we all fire up a tab with Gmail, Facebook, etc.
However, this still should not be ignored as we are keen to grap every single opportunity (audience/customer) and work with is at least better than falling apart. It still works!
As a Microsoft Development Platform user, there is a convenient solution on .NET platform. That don't require dual effort on such issues. Make use of your client-side validation while scripting is disabled by using Page.Validate() and Page.IsValid.
protected void Page_Load(object sender, EventArgs e)
{
if (Page.IsPostBack) {
Page.Validate(); // If you missed, then you got the second chance ...
}
}
protected void btnSubmit_Click(object sender, EventArgs e)
{
if (Page.IsValid) { // Confirm you do a proper validation before moving to perform any process
Response.Write("Done!");
}
}
I hope this will help.
Client-side (Javascript) validation is about usability, nothing else. If the cost of implementing is not worth the perceived increase in usability, then don't spend the time on it. These days it's pretty easy to do though!
I don't think you can do without server-side validation, however, since this is the only thing that provides you with any security.
Using JavaScript is not wrong. We've been using it since a long time. It is used for applying client-side validations.
Still, we should implement server-side validation so that a bad guy would not be able to break the application.
If you learn only one thing from this topic, let it be this:
Never — under any circumstances — trust data from the browser and always validate request data on the server-side.
Should we ever use it now?
Yes, definitely. You do not need to validate an empty field on the server side. It is not something like validating an email's availability (uniqueness of email). If you are going to reject that empty field anyway, there is no point of sending it to server and making
server do extra work for it.
You have to validate it on sever-side, javascript is good to validate form, but people can disable javascript, or use another javascript to hack it, so validation on server-side is a must.
JavaScript is useful for client side validation. But you cannot rely only on them. You must use server-side validation against the posted data. JavaScript just prevents unnecessary posts to the server.
You can make server and client-side validation pretty painless by using a framework that supports both. In the past, for ASP.NET I used the Peter Blum validators:
http://peterblum.com/
With this, you drop the validation controls onto your page, hook them up to the inputs (textboxes, drop down lists etc), and specify the validation properties (minimum length, required, error message etc). When the page runs, the framework spits out equivalent code for both the client (JavaScript) and server (ASP.NET) to perform your validation.
Without such a framework, as other posters have pointed out, validation can be laborious.
I'd be interested to know of anything similar for PHP or other technologies.
You should have multiple layers of validation.
Validation on the client Side
This is definitely useful because validation can be done without having to go to the server. Requests get to the server once they are validated - saves some traffic.
Validation on the server side
If javascript is disabled then the server should also incorporate a level of protection - validation in order to disallow erroneous requests.
In a multi-tiered / service orientated environment validation should exist on multiple levels to allow for better reuse while still maintaining a secure application. Validation on the client side, whether in a desktop app, or web site/application should be there for a better user experience to prevent postbacks to the server everytime for validation, hence costing more bandwidth and user time. If client-side validation cannot be moved entirely to the front end then consider using ajax for a partial postback to a server side validation routine, while retaining a better customer experience but allowing a programmer to maintain the validation rules centrally.
Second to the client side, but more importantly, server side code should validate the data before persisting it via a data layer or passing it to another server side method/service, to employ business rules around the data and help prevent errors in data integrity. Lastly, the persistence layer itself (the immediate interface to the database or other storage mechanism) should validate the data being stored, again to prevent errors in data integrity and possibly further business rules. The last thing you want is a data store with useless data.
Employing this method will keep you data secure and integrity in line. On reuse of either you persistence layer, your data layer or your front-end presentation thereafter, in your own site (or via a web service, desktop application or mobile app), if designed properly, these validation routines are already in place and can be re-employed. This should prove to be of great benefit to you alone, and your colleagues and your management, if you happen work in a team.
Is JavaScript validation worth of it?
well,yes it is .Buy using JavaScript validation you can easily take any kind information about client site more over JavaScript validation provides a better user experience
Should we ever use it now?
Yes you can because of user can see there error or what's they do wrong on real-time
Are there any solutions to this?
yes you can also use server-side validation.But sometime its take more time .it's also insecure
Javascript is a client-side scripting language. Therefore we can use client-side validations by using it. It helps to reduce the load that goes to the server-side. That's why js validation is worthy. And that is the reason for use it for client-side validations. But we should not only depend on js validations. Because the client can turn off the js engine at any time. If so, it causes a big problem.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
One argument for using both client side validation (JavaScript) and server side validation using a validator is that if the client browser does not support JavaScript or JavaScript has been turned off deliberately, then client side validation is rendered useless.
My question is how good is this argument in practice? In theory it makes sense, but in practice, if JavaScript is disabled in the browser, then most website features will not even work. The user probably cannot even load the page without JavaScript, let alone submit a form.
Client-side validation just avoids the client from going "but I filled this all in and it didn't tell me anything!". It's not actually mandatory, and in reality, client-side validation is a very new thing (read: 5 years old or less). In practice, all it does is prevent your client (with JS enabled) to know whether the form is okay before reloading a page.
If AJAX is in the game, it is different - it allows you to save bandwidth as well as to provide user with feedback before submission.
Finally, if you're building strictly client-side, peer-to-peer exchange apps (think games), you'll want client-side validation to keep the clients from cheating.
Server-side validation is also crucial due to the fact that client-side validation can be completely bypassed by turning off JavaScript. In a way, JS-driven validation is a convenience and an aesthetic/cosmetic improvement and should not be relied upon. Furthermore, it is trivial to edit the source of a page locally in order to disable or bypass even the most complex of JS validation.
What could a user do if you do not server-side validate? Anything, depending on how you use their data. You could be allowing users to drop entire databases (or worse, leak them), modify anything they like (or worse, read anything they like. Directory traversal flaws are extremely common entrance points for naughty people), and elevate their privileges at will. Do you want to run this risk? Not validating user input is like trusting people and not installing locks on your house.
Validation should always be performed server-side - you can never trust client-side validation.
Client-side validation is always in the sense of providing a better User Experience (UX), so the user doesn't have to submit and reload a page simply because a value in a form isn't valid - it makes things more dynamic.
As you don't even need a browser to make requests, independently of your website relying on JS to work properly, you will need server-side validation and sanitize all user input in case you care about not having your databases pwned.
Now it is up to you whether you want to provide an UI with dynamic client-side validation hints or not.
Always protect your inputs on the server. It's not always about users having JavaScript disabled but also that they could break the server.
For example, if a site has a JavaScript max-length check on an <input>, a user can could disable that check, thereby sending more data than your server and/or database is expecting. This could overload the server by a large POST occupying a server thread for a long time, it could expose a weakness in the database for example violating a database constraint potentially exposing details about any persistence information. Worse, if there is no constraint a user might be able to perform injection attacks.
Another example is someone using an external HTTP tool to send requests to your server, completely bypassing any JavaScript. I use the Advanced REST Client for Chrome all the time in development for testing JSON APIs.
Client side validation through JavaScript is just a way of providing a quicker feedback to a person using the site of any information about their interaction with the site. In traditional client-server communication it should not be the only validation for the reasons outlined above.
If a user has disabled javascript is a problem of himself and he decided alone to disable the javascript for a reason... For that, when you making a website you must have always in mind that your web site must be valid for users with and without javascript. The both side validation is needed for a number of reasons, some of them are:
User has disabled javascript
An evil user in purpose has removed the javascript in order to exploit the system
With javascript validation you reducing the data traffic between the website and the client.
And of course with server validation you make sure once for all that the data are correct
It is possible to have a website that is using both javascript and "older" technologies to be valid for every user and every browser.
Client-side validation is a solution for highly interactive forms with on-the-fly field validation, but it will not prevent a ill-intentioned user from injecting and posting invalid formatted data to the server. It is important that your server-side script validates everything the user is doing, otherwise you will expose your site to SQL injection attacks, XSS attacks, users doing stuff they are not supposed to etc.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
One argument for using both client side validation (JavaScript) and server side validation using a validator is that if the client browser does not support JavaScript or JavaScript has been turned off deliberately, then client side validation is rendered useless.
My question is how good is this argument in practice? In theory it makes sense, but in practice, if JavaScript is disabled in the browser, then most website features will not even work. The user probably cannot even load the page without JavaScript, let alone submit a form.
Client-side validation just avoids the client from going "but I filled this all in and it didn't tell me anything!". It's not actually mandatory, and in reality, client-side validation is a very new thing (read: 5 years old or less). In practice, all it does is prevent your client (with JS enabled) to know whether the form is okay before reloading a page.
If AJAX is in the game, it is different - it allows you to save bandwidth as well as to provide user with feedback before submission.
Finally, if you're building strictly client-side, peer-to-peer exchange apps (think games), you'll want client-side validation to keep the clients from cheating.
Server-side validation is also crucial due to the fact that client-side validation can be completely bypassed by turning off JavaScript. In a way, JS-driven validation is a convenience and an aesthetic/cosmetic improvement and should not be relied upon. Furthermore, it is trivial to edit the source of a page locally in order to disable or bypass even the most complex of JS validation.
What could a user do if you do not server-side validate? Anything, depending on how you use their data. You could be allowing users to drop entire databases (or worse, leak them), modify anything they like (or worse, read anything they like. Directory traversal flaws are extremely common entrance points for naughty people), and elevate their privileges at will. Do you want to run this risk? Not validating user input is like trusting people and not installing locks on your house.
Validation should always be performed server-side - you can never trust client-side validation.
Client-side validation is always in the sense of providing a better User Experience (UX), so the user doesn't have to submit and reload a page simply because a value in a form isn't valid - it makes things more dynamic.
As you don't even need a browser to make requests, independently of your website relying on JS to work properly, you will need server-side validation and sanitize all user input in case you care about not having your databases pwned.
Now it is up to you whether you want to provide an UI with dynamic client-side validation hints or not.
Always protect your inputs on the server. It's not always about users having JavaScript disabled but also that they could break the server.
For example, if a site has a JavaScript max-length check on an <input>, a user can could disable that check, thereby sending more data than your server and/or database is expecting. This could overload the server by a large POST occupying a server thread for a long time, it could expose a weakness in the database for example violating a database constraint potentially exposing details about any persistence information. Worse, if there is no constraint a user might be able to perform injection attacks.
Another example is someone using an external HTTP tool to send requests to your server, completely bypassing any JavaScript. I use the Advanced REST Client for Chrome all the time in development for testing JSON APIs.
Client side validation through JavaScript is just a way of providing a quicker feedback to a person using the site of any information about their interaction with the site. In traditional client-server communication it should not be the only validation for the reasons outlined above.
If a user has disabled javascript is a problem of himself and he decided alone to disable the javascript for a reason... For that, when you making a website you must have always in mind that your web site must be valid for users with and without javascript. The both side validation is needed for a number of reasons, some of them are:
User has disabled javascript
An evil user in purpose has removed the javascript in order to exploit the system
With javascript validation you reducing the data traffic between the website and the client.
And of course with server validation you make sure once for all that the data are correct
It is possible to have a website that is using both javascript and "older" technologies to be valid for every user and every browser.
Client-side validation is a solution for highly interactive forms with on-the-fly field validation, but it will not prevent a ill-intentioned user from injecting and posting invalid formatted data to the server. It is important that your server-side script validates everything the user is doing, otherwise you will expose your site to SQL injection attacks, XSS attacks, users doing stuff they are not supposed to etc.
Hi I'm new to dynamic web dev. I've searched this site but couldn't find anything similar.
I want to implement a password checker, for robustness and length etc. Fairly conventional. The thing is, I have 2 options: 1. embed javascript inside an HTML. 2. embed javascript inside a jsp file.
With a little preliminary research it seems that most people recommend the former, that is to go with HTML. I wanna know why? I could be completely wrong, in that case I also wanna know why?
The "how" isn't all that important, but "why".
Edit: I know this question is full of flaws (for example JSP and HTML aren't mutually exclusive) but please indulge me a little bit and tell me which scheme is more appropriate, if I want to get things done front end, in a user's browser.
Edit#2 : Sorry I did not provide any bg information: I am working on a larger project and password checker is just a part of it, the project itself is a dynamic web project relies predominantly on java, serverlet.
As you state you are new to dynamic web dev. JSP is a server side programming language Just like PHP and others. If you want to confirm password, you can use ajax to check for a match from your database and if match was found create a session and redirect your user to the logged in page. If i misunderstood your question, please try to be clear enough.
Depends on your use-case. In some cases, just the front-end is enough. In many, I would say both is better.
By putting it in the front-end/client-side (the "HTML"), you create a more user-friendly approach, since you can rapidly and continuously evaluate the users' input and give them feedback.
If the application doesn't need to be particularly robust from a security perspective, this can be plenty.
The downside of HTML only validation of any user input is that it can easily be bypassed. As a programmer, I could figure out what its doing and easily bypass any and all client-side protects. Users can also wholesale just disable JavaScript, so if your site works without JavaScript in general, they won't get any validation. This is why "security" on the client side is never a thing. Never trust the client.
Implementing it only on the back-end/server-side ("JSP"), you can lock down the security since the end-user can't bypass any of your validation. It must match the rules you set forth.
The downside to server-side is that you must send the data to the server to be analyzed, then wait for a response. While this may be fast, its still much slower than client-side.
By doing it in both, you get the best of both worlds. You get the rapid feedback for the end-user without having to send any data to the server, and you get the full protections of making sure it is properly validated on the server-side.
The downside to this of course is you have to double-up on your code, so its more effort. That's why you want to weight the pros and cons in your particular case, as there isn't a single "best" answer.
If the HTML is enough for you - why should you use .jsp?
You need .jsp for creating dynamic content and it's gonna be compiled as Servlet - do you actually need Servlet in this case?
If security is not a big concern then HTML + javascript should be fine. It will be responsive amd lead to better user experience.
If this is an external facing application on the web then as mentioned in some of the other answers go with Jsp approach.
In my LAMP application I am using Javascript for form validation but of course internet users can switch Javascript off in their browser so I also validate the form data on the server using a PHP function.
Does anyone know if there is some clever way to reuse my Javascript validation on the server so as to avoid writing a PHP version?
It's a little difficult to tell without knowing how you've constructed your application, but it's unlikely you'll be able to recycle your JavaScript on the server side. On the other hand, if you construct a lightweight, fast php validation tool you can use server-side validation via XHR instead of (a lot of the) JavaScript, and save yourself some redundancy the other direction.
However, that way's bound to be slower, so the best combination of user experience and security will probably come from having some redundancy in your validation.
This might be what you are looking for. It is not a javascript implementation. But this should provide all of your basic validation methods. I do not believe you would be able to find anything close to javascript unless you are using Node.js
Validator.php
I see all those tutorials about how one can use Javascript for input validating (checking to see that the email is valid for example), but nothing is stopping someone from loading the form, disabling Javascript, and then submitting the bad input without passing through the tests.
I tried to think of a way that lets you overcome this, and the best thing I could come up with is having a hidden input field and onsubmit after input validation a special value is inserted there using Javascript. Then if the server sees that it wasn't inserted it can tell that something is wrong.
But again, the js file is sent to the user, they can see the HTML, it shouldn't be too difficult to get around this as well.
The more I think of it the more I'm sure that there's no point in validating things using javascript because you will need to repeat the tests on the server side anyway, which begs the question of why people even bother with Javascript as a validating tool.
Am I missing something?
While server-side validation is a must, client-side validation using Javascript is definitely recommended.
Interactive feedback. The user can see immediate feedback as to whether or not his input is valid.
Limit page refreshes. Server-side validation requires a query to the server while client-side does not. Most validation "failures" are due to missed fields or invalid data which can be easily identified by javascript validations.
There are numerous libraries out there that can assist in adding general client-side validation using javascript. Most of them require almost no effort to incorporate into a form.
JavaScript allows you inform the user about mistakes and misunderstandings without extra network load and waiting time. Of course, it doesn't prevent submission of intentionally wrong or even wrongdoing data, and you need to perform secondary checks on the server side.
The only way to make client-side validation robust, is to repeat it on the server.
The reason people bother with client-side validation, is one of user-experience. Client-side validation gives instant feedback - server-side validation does not. Also, in a high-load situation it will help to take some load off the server by not allowing invalid forms to be posted.
Client side validation has the point of providing fast feedback to the user, I don't want to hit submit 100 times just because I typed a phone number wrong or I missed something else.
All client side validation really does is provide a better User Experience, since in the end you can NEVER trust the client.
Client side validation eliminates the need for a network round trip to the server and improves the user experience.
Server side validation protects the data integrity. Never trust the user and rarely trust the programmer.
JavaScript validation can be never trusted. It's a user friendly way to tell the user he fails. http request can always be made to add invalid data.
JavaScript is running on the client machine. Clients can not be trusted. They make mistakes, do stupid things that you didn't think of to get around validation, disable javascript so they feel safe, create custom http requests because the feel cool they can "hack", etc.
Users are stupid, evil, clumsy, unreliable and sometimes even smarter as you.