A simple user registration may be completed by PHP (framework: Codeigniter,etc..) and Javascript.Following is simple flow:
PHP
A registration view with form input(user_name,e-mail,password)
post the data to an controller to validation
-Pass, redirect to a completion view
-Failed, go back to the registration view with some alert strings.
Javascript
A registration html with input text(user_name,e-mail,password)
Validation could be done by Javascript directly before submit; Alert strings could be
generated by Javscript. Even submission could be done by ajax. Then redirect to the
completion page.
I found myself code more javascript less PHP. Even the user registration could be done without the "form" tag,right? I am afraid of some parts I had miss or ignore.
Could someone gives me an simple comparison of good/bad parts about these two methods?
User registration details have to be stored on the server. You can use any language you like there, JavaScript (node.js is the current preferred way to achieve that), Perl (PSGI/Plack), Python (WGSI), C# (ASP.NET), PHP (mod_php), whatever. If you did it entirely with client side JavaScript, then the registration would exist only for a particular browser (which makes it rather pointless for almost anything on the WWW).
You can do a lot of things with client side JavaScript.
You can test if the data enter by the user conforms to the requirements you've set (such as "usernames contain only ascii alphanumeric characters").
You can't stop data that doesn't conform to those requirements being submitted to your server though - everything outside your server is beyond your control. Users can edit your pages in their browser as much as they wish. Client side validation is a convenience to the user (giving feedback without a server round trip and page reload), nothing more.
You can use Ajax instead of an HTML form … but there is no reason to do that. It just adds an unnecessary dependancy on JavaScript. That doesn't mean Ajax can't be useful, you could use it to ask the server if a username was already taken while the user is filling out the rest of the form.
Related
I have my website which has this issue. It could be hacked easily through javascript.If the hacker types this in his console he can easily add a user in my database and can signup without going through the stuff like checking password length , checking username length and so on ...
$.post("extra/includes/signup/register.inc2.php",{username:"user1234",email:"email#live.com",p:"here goes password"})
I want a code that could stop him from using console in my website. And if there is no way to do that then how to fix it by some other means ?
Disabling the console won't do. A hacker can always do the same request to your server as you do.
If it is something that isn't public you can protect it using a username and password, looking at the url it is a public script.
If you require a public register script the best way to protect against this kind of thing is to us a captcha (for example recaptcha. It makes it a lot harder to do a scripted attack on your register script.
Always validate the data server side, you can not trust the data you receive from your request because it can be easely manipulated.
You should not rely on client side form validations and it is total bad practice.Try to adapt framework like CI or Laravel . They have particular set of easy ways to validate the form inputs .
Ok, so currently I handle all HTML form submissions in PHP. I submit the form to a PHP file which:
Checks against a cookie created at page load to prevent CSRF.
Contains a require_once() that handles validation.
Runs other logic.
If any of these steps fail, the user is redirected in PHP to the page they came from with an error message.
How I submit the form:
<form method="post" action="filename.php">
This system is fail-safe; as if anything goes wrong, the user is returned to the page they came from even with Javascript disabled.
So my question is; can I create a fail-safe system using just Ajax (an Ajax request to the server on form submission)? So that I don't need this PHP system at all? Is there a recommended procedure/tutorial for this?
I've avoided this so far as the overhead of having both a PHP form handling system as a fail-safe for potential hackers, as well as Ajax, can take several hours per form.
Just to clarify, I don't require support for users that have Javascript disabled. I just want to make sure my system if fail-safe in that situation. I've had a good look around, but it's proving difficult to find clarification on this.
The short answer for the most part is: no.
It is unwise to consider anything client-side as reliable or fail-safe, this is especially true when it comes to validating user input. A rule of thumb is: never trust the user.
Currently, per the description, your form is being submitted to a PHP script that validates form data. This way is going to be your best line of defense since you have a large amount of control on the data you are working with.
It sounds like you want to cut out the form submission and not force another page load. You can use AJAX to pass form information for validation to your script, but your PHP code is still going to be crucial to the validation process.
Basically you want to make your PHP validation solid. Next, start adding some AJAX calls that pass information from forms to your PHP code, but be prepared to fall back to standard form submission if AJAX is unavailable. If there are no problems with AJAX, you can still submit the data, have PHP do its processing, then return a payload indicating success or failure. Keep in mind though, in this context AJAX is just some sugar for the validation. You are only sweetening the deal by saving yourself having to reload a page and transfer the entire document again.
But remember: it is not reliable, and it is not fail-safe. Server side validation is the light at the end of the tunnel.
If you create a form using HTML inputs and make the input required using the "required" attribute (<input type="text" required>), what is stopping a user from manually deleting the attribute by using their web browser's built in developer tools or by loading JavaScript by some other means (such as a bookmarklet)?
In other words, how can you ensure the required input remains required?
The client/browser has little control over the request that is sent to the server. A request can be constructed and passed to the server without involving a browser, therefore its the server side code's responsibility to ensure that the required parameters were provided with the request (as well as validate the parameters).
You need to consider a few things:
Everything on the client side can be modified by the client: nothing is stopping me from using my browser console or modifying the source code to change parts of your page, and you can't do anything to stop that. For instance, look how many upvotes your question has:
Obviously that doesn't actually do anything, but that's because all of the heavy lifting is done by Stack Exchange's servers.
Even if you make a field required, people can still fill in the field with a space or asdf and move on. Just because input is required doesn't mean that it is valid.
So, with that in mind, realize that you'll need to work on the server side to validate input. People can't mess with servers (easily) and it's the safest way to validate input. You'll need to deal with validation when your server receives the data because the client side is always vulnerable to user modification.
Before submitting a form, i use javascript code (surrounded in PHP) in order to make locally some controls but sometimes javascript may not be enabled client-side.
The fact is that I have to check by pattern/regex each control of the form for example checking email, phone number,.. format so that user cannot enter anything haphazardly. Therefore, if javascript is not enabled, the form must not be submitted, even if all field are fulfilled out.
Therefore my question is to know if there is a tag or function which allow to perform what i want to?
Thank for your help
JavaScript runs client-side.
That means that users have FULL CONTROL over it.
Then, if they want to disable it, you can't do anything about it.
The only thing you should do is be sure that users with JS disabled will be able to submit the form too.
If you use JS to validate the form, be aware that users have FULL CONTROL over it, so they can send the form if they want, even if your code says that it's invalid.
The right way to do it is:
Be sure users without javascript can send the form
Implement client-side validation for users with javascript activation. This way they will have a better user experience (because can know if the data is invalid immediately) and is less server intensive (your server will have to validate less invalid forms).
ALWAYS validate the submited form server-side. Data coming from a client is always UNTRUSTED, even if you think you have validated it.
i am using gwt.
i need to check some input data.
all checking functions are located in PHP server check.php
i am not using javascript checking executed from locally.
all i am doing is to send user input to server by ajax and validate in that place
and error message comes from server to client's gwt widget.
is it best approach??
i can do all checking from locally.but not doing.because server side is importent.
all checks must be resides in server so i am doing all checking from server.
if i do check locally and serverside two times ,then will it be best approach??
What you'll want to do is:
Use this account the next time you come back, or any of the others you've created, instead of creating an account each time you come to the site. Avoid this mess.
Create a .php page that accepts JSON-encoded data that you'd like to verify, and respond with some text like "OK" if it's valid. (I'm no PHP expert, but I'm sure there are plenty of them here)
Use GWT's RequestBuilder to send this data to the .php page, and call the RequestCallback's Response's getText() method. Check if the text is "OK" -- if so, the result is valid!
If you need more detail on any of the specifics, just let me know and I'll edit to clear things up.
Generally I agree with Jason (especially the with the first point :D).
I'd like to add that you should do validation on the client side first. Why? Because it allows you to weed out some obviously wrong inputs => less load on the server. But never accept the values from the client, just because your JS code said so - the general rule is to never trust the client side (because, well, it's the client side and the client can change the way your code works).
So in summary, I usually take these steps in my apps, they offer security and lower the load on your server, but may require a bit more work to write and maintain (especially if your client side and server side use different languages):
Validate input client side. If it doesn't pass, don't bother sending it to the server, just show an appropriate message.
If it does pass, send it to the server, but you must rerun the validation on the server side too.
If the server side validations report an error, send it back in some form (JSON with the error message and/or error code, set a HTTP response code, etc).