While looking for a way to speed up form validation on a large number of fields I build my own library of php validation functions to be re-used across multiple websites. I am now trying to avoid duplicating these rules in javascript without sacrificing user-friendliness.
I am thinking of storing attempted inputs in a $_SESSION['attempted_inputs']
Upon failed server-side validation, user would be redirected back to the original form where an error message will be printed and all fields will be prefilled with attempted inputs, thus eliminating the need for JS validation.
Assuming attempted inputs will be properly sanitized upon saving and server resources are not a concern on my clients small-scaled applications, what could be the downsides of using this method instead of a classic js client-side approach ?
Thanks
Downsides:
Unnecessary start/save/delete of the session. The GC process could do a lot of unnecessary work. You could use a POST back style instead of session saving. I know you said you don't care about performance, but this could bite you back someday.
Slower validation. Going back and forth with the form isn't a nice UX. If you can say what's wrong before posting it, you should do it.
If i can think of more downsides i'll edit my answer.
While this is not the right place to ask for concepts, I just wanted to give you a quick heads-up.
You should always validate your inputs on the server side. Manually changing requests these days with tools as the developer console, makes your application really vulnerable to many kinds of attacks.
Related
So I posted a question the other night and an interesting reply got me to thinking. I've always done things a certain way and I try to be as safe as possible but I'm wondering what else I could be doing. This isn't related to a specific piece of code so much as a concept.
The layout is jQuery/PHP. Standard HTML and CSS.
Scenario
I write a signup form. The form includes email, password, first name, last name, zip code.
When the user submits, jquery picks it up, prevents default and submits for validation through ajax. On the php side, I'm going to verify lengths, symbols, values, etc to try and get the best possible read on the data. If it works, I continue with the signup. If a flag is tripped, I return a JSON string that has a message, an error status and other relevant information. I'm doing it this way instead of checking the jquery because of the ability for the user to open the script and make changes.
On the php side, I can only work with the information that is received. I use POST and I only call for the variables that I'm looking for. Nothing can be added to the php this way...at least not easily. I'm also using PDO and prepared statements for inputting to the db for an extra measure of security.
My question is this. When you guys are validating data, what other steps do you take to prevent security breaches? I only know what I know so this is why I ask. I'm always looking to make my code better. Obviously there are a dozen functions I can use like striptags, strip_slashes, etc but I'm really curious what everyone else does in case there might be something I could be doing better.
I tried google but looking for validation and error checking really just returns the obvious broken scripts and code snippets but not much in the way of conceptualizing a better way of doing things. Just looking for some general feedback. Thanks!
I have looked through many threads and/or questions on the internet looking for a clear answer but so far havn't gotten any.
A part of the question was already answered (unless you tell me it is wrong). Data validation should be done client side AND server side. Client side to notify the user of data who is invalid and to offload the server and as well on the server to prevent any kind of attacks.
Validating on both sides can be a tedious task though and I wondered if there was some way to do it so that you don't have so much duplicated code.
There is also something else I was wondering...I have a table with rows who contain the id (of the database) of that row. At the end of each row I have a delete button to delete it from the html, my JSON object who contains an array of my values and who is sent to an ajax call to be deleted from the database (a link between 2 tables).
This isn't safe (well in an unsafe environment like the internet) and I know it. I can always check client side to see if the id is only numbers and if so then check server side if it exists. But who tells me the user did not go in the debugger and inverted 2 lines and end up deleting rows who should not be? What would be the best way to have my ids and be safe from people inverting them?
Any suggestions appreciated
Data validation should be done client side AND server side.
It is not really needed to do it client side IMHO. But it is nice to be able to notify the user before submitting the data. So I would call it a pre.
Validating on both sides can be a tedious task though and I wondered if there was some way to do it so that you don't have so much duplicated code.
Because PHP is serverside and javscript is clientside it isn't really easy to prevent duplication of code. There is one way that I know of however using xhr requests. This way you can use the php validation in javascript (clientside).
At the end of each row I have a delete button to delete it from the html
Please tell me you are using CSRF protection. :-)
I can always check client side to see if the id is only numbers and if so then check server side if it exists.
To prevent malicious sql injected you should use prepared statements and parameterized queries.
Validation should always be done on server. Client-side validation is for user convenience only and is not strictly necessary from the security point of view (except when it opens a XSS security hole).
Apart from that, you should sanitize every input you receive from user. After the input has passed a sanity check (for example if there is text where there should be a number), you should do a permission test (Does the user have the appropriate permission to perform an action that is requested?)
After you have done this, you can actually execute the transaction.
Since other answers have already been posted, i would recommend that you dedicate a utility class that you can call Utility and where you would store many useful functions to check data type & content in the server side, that way even if you'll be doing some great verifications on both client and server side, at least your code will be more readable and manageable.
Another benefit of creating and managing your own utility classes is that you can easily use them across all your projects.
For example, a utility class can contain methods ranging from verifying that a certain field is within a specific range of values, or that it doesn't contain special characters (use Regular Expressions) and so on ... Your advanced utility method would focus on preventing scripts insertion, sql injections as mentionned before.
All in all, you'll do the work once and benefit from it all the time, i'm sure you no want to start checking if an age field is negative or whatever on every project you do from scratch. Using Ajax and XHR can be a bridge between your server side and client side code and would help you unifiy your validation and avoid duplication.
What is the point in validating your HTML forms using Javascript, if you are always going to need to validate the forms using PHP anyway? I realize that you get a speed boost from this, and its more convenient to the user, but beyond that, is the time spent on it worth it? If anyone has any good evidence on this I would love to hear it.
Thanks for any help!Metropolis
UPDATE
After receiving numerous answers I would like to change the question a little. We all know that javascript is much more convenient for the user and it gives faster feedback. What I am wondering is: Has anyone ever seen any "evidence" that its worth it? Or do we just do it because it makes things a little better and everyone says we should? The speed difference is not that significant, and as the internet gets faster javascript validation will become even more obsolete I would think.
I am starting to wonder if the time spent validating a page using javascript could be better spent.
Ideally, you validate through javascript and (in your case) PHP.
Both validation methods will work in-tandem to ensure you get the most robust and user friendly functionality possible for your end user.
You will use client-side validation to ensure that all fields are filled in, email addresses are valid, etc.. this will provide instant feedback and won't burden your servers or the user's internet connection.
you validate server-side for security. You can control everything on the server and nothing on the client machine. It's here that you ensure that all entered data is non-malicious and correct.
Keep this in mind: if you are only going to go with one type of validation, choose server-side validation because it is more secure. You should never rely on client-side code for any kind of security.
Using both types of validation gives you the best of both worlds (responsiveness and security) while having none of the downsides. Of course, this means you have to write more code, but in my opinion, it's worth it.
EDIT: In response to the comments
Yes, you have to write more code this way... As a rule of thumb, if it's harder for the programmer, it's easier on the user. It might not make sense in some budgets to do both types of validation and that's a call you're going to have to make. Just make sure your server side validation is rock-solid regardless.
Yes, time is money, and time invested in improving the user's experience is time well spent. If you can't afford to do it now (deadlines/schedule/budget) then do it when you can.
It's all about usability. It is much more convenient for the user to read what errors they have made before the page reloads, rather than continuously submit and reload the page. It can also give a nicer look with some AJAX and the likes, rather than a reload of the page and the very ugly looking red error messages, I think. So the advantage? Much more usable than having server side validation alone.
To provide a better user experience.
The feedback on JS validation is faster, and therefore better than server-side validation on form submit.
The main point of JavaScript validation (when available) is that it improves the user experience. A round-trip to the server requires a page load and the associated annoying flicker as it redraws. Validating in JavaScript code allows you to display a message without all that.
That being said, server-side validation is still required since JavaScript isn't always available (NoScript is quite popular) and because a malicious user will bypass the JavaScript.
Particularly for database backed websites, it tends to be that you need to do server side validation anyway. e.g. to make sure you're inputting valid data into a database or other system. Depending on what the website is updating this could be absolutely critical.
However, client side validation can provide a better user experience. It can be used to provide instant feedback. e.g. when you move focus away from a text box a validator can provide instant feedback which is great when you're filling in a long complicated form.
The bottom line is that you will still need to input good data into your database. And the more correct the information stored in there, the less problems with the system you'll have later. You need both.
e.g. What if someone updates the website code in the future and breaks the validation? or someone writes a script to automate inputting data, bypassing your web front end all it's validation?
I'll say it again. You need both.
...i think you're also keeping your karma cleaner, when hundreds or thousands of your users don't wish you burn in hell for making them fill in 5-7 fields (with textarea) to be informed on the next page they mistyped their email so they have to start all over again :D
it doesn't eat up much of my time to incorporate javascript, id say 1-2 minutes maximum for 1 form. and it saves lots of nerve cells of my users. be a humanist! love ur neighbour!))
Client-side validation allows for an increased user experience. The feedback you give to the user leads to less frustration, less errors, more conversion, more money.
You generally have a better response rate with this kind of validation, which is very valuable.
An high quality software needs this. Users feels happy, and they will spread their joy. A user who has a bad experience won't come came and won't tell his friend.
It's not only decoration when you get to business and sales. ;) The return on investment is worth it.
Easy.
Javascript to help the user enter correctly formatted data.
PHP to make sure whatever enters your script gets cleansed before further processing.
Ofcourse you'll have to do both. Users want it, your customers want it and frankly, you think it's fugly getting php errormessages after submit aswell.
I don't think the argument of having to code extra .js which presumably would eat up your time/budget holds any thruth. There's so many libs and scripts outthere, either one will enable you setting up disco validation in no time at all. However, don't get carried away with dealing out eye candy. .js validation is just there to help. Not to impress.
PHP runs serverside, javascript runs clientside. You don't want your server crunching form validation when you can get the clients computer to do so. Plus it saves bandwidth.
We're in the first steps of what will be a AJAX-based webapp where information and generated HTML will be sent backwards and forwards with the help of JSON/POST techniques.
We're able to get the data out quickly without putting to much load on the database with the help of a cache-layer that features memcached as well as disc-based cache. Besides that - what's essential to have in mind when designing AJAX heavy webapps?
Thanks a lot,
Probably the best thing to have in mind is that your app shouldn't be AJAX-based. It should work fine if the user's browser has scripts disabled. Only then should you start layering on AJAX. Stackoverflow is a great example of this. AJAX really improves the experience but it works when it's disabled.
Another thing I like to do is to use the same PHP validation functions for both server-side and client-side validation (as in sending an AJAX request to a script containing the same PHP function) to keep the amount of cross-language code duplication to a minimum.
Read up on Degradable AJAX.
Security for one. JavaScript has a pretty notoriously bad security profile.
These are the two that always get me:
What happens when the user clicks multiple items that may trigger multiple requests that may return out of order?
What happens when a request doesn't come back for one reason or another (timeout, server problem, etc.)? It always happens eventually, and the more gracefully your system fails the better.
This is a technical design question more then a syntax question.
I have a large page with 9 forms corresponding to different tables. I've wrestled with the design and I there's no way out I have to send all the forms via ajax to the server for processing. There are lots of interrelations. I can't combine the forms into one large one either. So the question is what's the best way to send a lot of forms via ajax. To further complicate the issue there are dynamic forms with fields with same names.
I'm trying a technique of:
1. serializing each form,
2. prepending the form name to each field name
3. combining the serialized version of the forms into one
4. posting that combined serialized form to the server as one
5. breaking them apart on the server side into separate arrays and then finally doing the application logic
I just don't know if there's a tried and true easier solution and I'm making a mountain out of a mole hill
If there's genuinely no way to redesign the page, then your solution seems simple and straightforward to me, not at all "mountain"-ish. To me, though, your description of the page screams "redesign," though of course I don't have enough information to work with.
One such redesign would be to send field changes to the server as they happen, rather than waiting and submitting the entire thing. The server side can hold them as "pending" if you need the user to explicitly commit the whole thing when they're done. But that depends on expense of server resources, etc.
You should be able to send 9 separate AJAX requests without hassle (assuming that a: each doesn't rely on the response of another, and b: this isn't something which happens all the time).
Using your javascript library (you are using one, right??) just loop through your forms and AJAX submit each one. I think it'll probably only process probably 2 at a time, but if that's not a problem to your design, then all should be sweet.
It would certainly keep the PHP/Server-Side part of the equation much much simpler.
If you were working with a high-traffic site, then you'd probably want to reduce the number of requests being made, but chances are your current setup will work sufficiently well.
I'd prepare a javascript dispatcher which would smartly do the job of posting the data. So when the submit button is pressed it would collect all the data needed, and then send the data to the appropriate controllers on the server side.
It could block the form, in the meanwhile, or display a "Processing..." popup.