I read here that the main reason for using client side validation is:
the user can correct every field before they submit the form
This (sort of) assumes Ajax, but if the client side validation consists purely of Javascript, is there really a point to it anymore? It's easy enough to point out specific mistakes and store form data on refresh from PHP / Django / node.js, so if the client side script isn't pointing out mistakes as the user is making them, does it really make sense both from a UI and developer perspective to take the time to write that bit of code?
Client side validation helps you prevent errors from entering into your server/database and adds a second layer of protection.
As far as Ajax is concerned, you will be sending your data from the client to the server one way or another so if you're using Ajax or not is irrelevant.
From a developer's perspective, even something as simple as checking all the fields for valid data types on form submit is worth the effort. This saves your server from having to process an invalid entry and shifts that load to the user's system. For large scale applications this dramatically increases performance.
From a UI perspective, I understand that incorporating error checking into the form makes it a little bit difficult, but in my opinion this is a minor inconvenience to save you much more hassle of having to clean your database in the long run.
Edit: As Ryan pointed out in his comment to the question, users definitely appreciate feedback without having to wait for it
Related
With a practical perspective what are the pros and cons of AJAX /AJAJ compared with other standards, such as html post followed by
res.render('returnView', {outputVariable: V })
Would it make any difference if processing the input takes very long time at the backend ?
Is there any particular case where AJAJ would NOT be recommended ?
It's a very big question. In short way it's a holy war about server-side vs client-side, so I'm only going to write several pros:
Server-side:
User doesn't need to have JavaScript enabled on the browser. Nowadays it's a bit old manner, but sometimes when you deliver only information it's great.
It is easier to maintain and error catching. You can catch on the server most of the problems
Don't need additional code/application for monitoring errors on client side
Better SEO optimization for Google and other bots
Client-side:
Interactive pages - For instance, you might have a form that includes text inputs as well as an image upload/edit feature. Let's say the user writes some information on the text fields, then wants to upload/edit the photo without losing or submitting the information on the form fields. With AJAX / AJAJ you can have the user select the photo, crop, rotate, upload, you update the <img> element without reloading the page and losing the information in the forms.
Smaller data are downloaded by client because html has same overhead as a xml
Thiner server and cleaner API you can develop
More on topic you can read here.
I have a form users fill out and JavaScript is used to validate the input (e.g. makes sure the password field isn't left blank). Since JavaScript is client side and not compiled anyone can easily mess around with it. Does this mean it's necessary to validate data from the user again on the server? If yes, is there anyways it can be made more efficient since JavaScript (theoretically) already did it?
Yes, it is necessary to validate data on the server because it can be messed with by end users client-side.
If yes, is there anyways it can be made more efficient since JavaScript (theoretically) already did it?
It is already more efficient than having only server-side validation, because you avoid a lot of round-trips for validation by having client-side validation (you only need to submit the data once, and unless validation was incomplete or disabled, it will go through straightaway). Provides a better user experience, too.
You cannot do away with server-side validation (if you care about the data). If the data only ever goes back to the same user and is not shown or used anywhere else (and has no potential to break anything on your system), you could relax this a little. As as extreme example, Dropbox probably does not care what files you upload, so they don't validate if the HTML you upload contains malicious Javascript.
I can disable any javascript on your page just with a click of the mouse. I can even totally bypass an HTML form and send data directly to your server.
For example, if you retrieve data with $_GET I can bypass your form (and the javascript validation) just by messing with the address bar. Don't think that using $_POST would change this: it just a matter of writing an HTTP request.
So, yes... Never trust user input, even if sanitized with javascript.
As somebody posted above, javascript validation can prevent legitimate user errors (thus save the trip the wrong data would have done to your server and then back to the user) but malicious users will still be able to bypass it VERY easily.
short answer: yes and always!
read about PDO, SQL injection, UUID, tokens, MD5, SHA, Cross-site request forgery...You have a whole new world to discover! :) I mean it in a good way. Learn about this and you'll build more secure websites
You always need to keep this in mind: Never trust user input data. Never. So you have to perform extra validating process in server-side.
Yes absolutely. It is still possible for someone to intercept the form and modify values before re-posting to the server.
The user certainly can disable JavaScript. It is also very easy to mess with it as the source code is right there. The user can also run arbitrary JS, making it even easier to mess with your stuff.
Therefore, you should always do server side validation as well. Client side validation should only be used as convenient information for the user. Never trust it as your only security source.
Yes, you MUST validate both in client side and server side.
You must think in terms of progressive enhancement. Think of Javascript as just a layer for enhancement and not a necessity. Because it's always upon the discretion of the user to disable Javascript in their browser, rendering your Javascript code useless.
A plus in client side validation is you're saving roundtrips to the server validating if the username or password is empty which can easily be done in javascript.
Yes, to be safe you will need to add server side validation.
Nothing that is expected to have been done on the client side is guaranteed so you will need to repeat anything that is important.
Additionally there are things that are likely to be evaluated on the server side but not on the client side. Things like checks for SQL injection fall into this category.
I use some jquery and JS functions to validate forms and to check for example if that field is empty or password is less than 6 characters, and stuff like that, and I noticed that if someone disabled JS, then these functions would be useless, and no more protection of forms, which can be better made using PHP, so should I avoid them now because this could cause an insult to my website ?
JavaScript is very useful for improving user-interaction, along with reducing the number of requests made on the server; but, as you've pointed out, it can be disabled. To answer your question: No, I wouldn't recommend avoiding the use of JavaScript, but the key is not to rely on it for critical actions, such as validation. You'll want to implement the validation on both the client (JavaScript) and server (PHP) sides. This will ensure that there is no way for the user to completely disable the validation.
In short:
JavaScript = Good
JavaScript Validation = Nice for the user, but not reliable
Server Side Validation = Essential
Side note:
With regards to relying on JavaScript for the overall user interaction, as other answers have suggested, use JavaScript to enhance the overall experience, but don't rely on the user having it turned on. I would recommend a bit of bed time reading of Progressive Enhancement, it's the approach of making something better, with being reliant on it, and can be applied to more than just JavaScript (CSS3 etc).
You should use javascript and jQuery to enhance the functionality of your site. If someone has javascript turned off you should ensure that the site still works, and they can access all areas - even though there may be some things they cannot see, such as transitions and effects.
With regard to validation, you should ALWAYS validate server side. Client side validation is optional, but a very nice feature to improve the user experience for your visitors.
I don't mean this as a complaint, more of an observation.
Web developers often grab Javascript libraries as the latest shiny toys with no thought for the consequences. As a Data Governance person, I'm regularly the bringer of bad news, when we do audits on the data collected, and find users who get past the Javascript validation.
"Go back and start again".
Javascript libraries are great for the presentation of data, but should and must not be relied on for data validation and the integrity of user profiles.
A validation should always happen at
Client Side - using javascript to enhance the user experience.
Server Side - using the preferred server side programming language for security reasons
Service Side - if you are following SOA / Web API as part of defensive programming practice. This can also be at the DB level along with Service layer.
You should not avoid using JS and jQuery in your website, but you should avoid using them for validation purposes or business-logic purposes. These should be done in the back-end of the website, not in the UI level.
You shouldn't really avoid them. What you should do is to implement both client and server validation. Don't rely just on client validation, for the reasons you just mentioned. You should always validate the data when it arrives to server.
Adding client-side validation gives your pages dynamic look and feel. A user does not have to wait for the form to go to server and in case of an error to return back. It is automatically verified without postback.
As I said above, don't rely upon client side validation. Always implement server-side validation also.
Remember my friend, Java script is client side scripting. its purpose to validate form at client side itself so we can avoid overhead...You must use java script at client side. because PHp is server side language. It will take time to reply.
Ha, Server Side validations are equally important. if you want to do that, then you can use server side language. You can check comment below to my post by halfer. Server side validations are important for security and many more purposes.
That is different thing that somebody disabled js. You can check for the same and give proper message to enable.
I see that validating forms using Ajax can be quite useful to avoid code duplication. And before implementing it I am interested if the are any disadvantages of this technique comparing to simple javascript validation. I see only couple of arguments, but I think they are quite weak to take them into account:
It's obvious that ajax will increase server load, but it's only 5-6 connections per form which should not be a performance bottleneck.
Also I see that js validation can work offline, but as we need to submit a form in the end it can't work without Internet connection anyway.
Speed is also not the issue as now broadband is available almost everywhere.
Are there any other arguments that I miss?
Ajax validation is great from a user experience point of view, because you get immediate feedback.
One thing to keep in mind is that even if you validate the form using ajax, you still need to re-validate the submitted values once they hit the server to prevent security exploits, since an attacker could just use something like curl to send arbitrary values.
To take the contrary position:
1) 5 or 6 requests is no big deal - but 5 or 6 times as many connections per-user per-form - that is. If you are talking about taking your server from 100k to 600k connections a day, better think about it.
3) Broadband is everywhere, but so are slow and unreliable wireless connections. Depending on how you implement it, the form could feel very clunky.
And you definitely do need to re-validate on the server - but that's what you are saying: reuse that logic that is on the server anyway, via ajax, instead of replicating it on the client with JS.
Just a side note: Some frameworks allow you to declare validation in one place and then generate the Javascript (non-ajax IIRC) and the server-side for you. I know JSF (Java Server Faces has this) and I think .net does also.
If all you're asking is
I am just asking if i will validate
a form with javascript instead of ajax
will I gain anything that I can't do with ajax
then no. In the end point - you get a gesture for the user on his bad input.
However, I will not so lightly disregard server load.
5 additional requests per form - to redo on the server checks that it needs to do on form submit - that's about doubling the server work on your forms.
Also - mind that AJAX is also javascript, so you're not completely rid of it.
And last - JavaScript with server roundtrip (and AJAX is a server roundtrip) will not be as immediate as simple JavaScript.
However - yes. it is code duplication. That is your trade of, and any decision you make is valid if your project can take it.
Edit: fixed a typo + move to community wiki
Web-Applications these days make extensive use of Javascript, for example various Google Products like Gmail and Calendar.
I'm struggling to how NOT having duplicated logic server and client side.
When requesting a page or state of the application, i would prefer to send the complete UI, meaning: not just some javascript, which in turn makes a dozen ajax requests and builds the user interface.
But here lies the problem, the logic deciding what to show or not has to be written once in the server-side and once in the client-side language.
Then i was wondering if it was somehow possible to process your javascript logic server-side and send the whole to the client, who in turn can continue using the application with all the advantages of a responsive ui, but without disadvantage of the initial loading/building of the user interface due dependency of background ajax requests.
I hope the explanation of my problem is a bit clear, because i'm not the most fluent English writer. If you understand what i mean and if you can describe the problem a little better, please do... thanks!
So my question is:
Is something like this possible and or realistic?
What is your opinion on how to tackle this problem?
;-)
When we started our web app, we had the same kind of questions.
It may help you to know how we ended:
The backend (business logic, security) is totally separated from the frontend (gui)
frontend and backend communicate through JSON services exclusively
the JSON is rendered client-side with the PURE templating library
and the backend is Erlang (anything streaming JSON would be ok too, but we liked its power)
And for your question, you have to consider the browser as totally unsafe.
All the security logic must come from the backend.
Hiding or showing some parts of the screen client side is ok, but for sure the backend decides which data is sent to the browser.
Seems you describe Jaxer.You can write everything in JS. Also, there is GWT that allows to write whole thing on Java
Then i was wondering if it was somehow
possible to process your javascript
logic server-side and send the whole
to the client, who in turn can
continue using the application with
all the advantages of a responsive ui,
but without disadvantage of the
initial loading/building of the user
interface due dependency of background
ajax requests.
Maybe the apps you're looking at just use Ajax poorly.
The only content you can pre-process on the server is the content you already know the user wants. For example, in an email app, you could send them a complete view of their inbox, pre-processed on the server and fetched with a single request, as soon as they log in. But you might use AJAX to fetch a particular message once they click on it. Sending them all the messages up front would be too slow.
Used correctly, AJAX should make your pages faster, because it can request tiny updates or changes of content without reloading the whole page.
But here lies the problem, the logic
deciding what to show or not has to be
written once in the server-side and
once in the client-side language.
Not necessarily. For example, in PHP, you might write a function like displayWidgetInfo(). You could use that function to send the initial widget information at page load. If the user clicks the widget to change something, send an AJAX request to a PHP script that also uses displayWidgetInfo() to send back new results. Almost all your logic stays in that single function.
Your instincts are correct: it's bad to duplicate code, and it's bad to make too many requests for one page. But I think you can fix those problems with some refactoring.
I understand what you're saying.
But I don't think you should be having much 'logic' about what to build, on the client side. If you did want to go with a model like you're proposing (not my cup of tea, but why not), I don't see why you'd end up with much duplicated.
Where you would normally show a table or div, you would just output JavaScript, that would build the relevant components on the client side.
I would consider it just as another 'View' into your data/business logic model.
Have you go a small example of a problem you're coming up against?
I understand your question in this way:
Suppose we have an html form on web-page. There is a field for name and surname. We have to check it for validity both on client-side (with JS) and Sever-side (on php script while processing form inputs). So here is the duplication - regex check on both sides. So what is the way to prevent it and combing these logics?