Currently I'm using Ajax to check register validation, but I feel if the internet connection is not good enough, sometimes Ajax is not working properly and it makes users register with the same username. So how can I double check the register validation to avoid the duplicate usernames in my database?
If the field in your database is set to UNIQUE this won't be a problem since an error will be returned i.e.
CREATE TABLE user (
username VARCHAR(20) UNIQUE NOT NULL,
...
)
When an INSERT is run on this table but the potential username is already taken, an error will be kicked back.
Should I mention that while client-side validation is all well and good for being fancy on your webpage with the pop-up divs and highlighted spans, validation should always be rechecked on the server-side.
Other than setting the constraint on the column username to be unique, you should be doing a QUERY prior to creating a record to check for any errors, sounds like you are relying on just Javascript to validate your input.
Solve your validation first! Don't depend on javascript doing it, need it on the front end (html view) and backend code (php)
well its just an idea, I am pretty sure You do the validation on change or blur event of the input. But the registration will be done by submit button. If I right, Just add some script to the registration-proccess-page that check if the username is exist or not, if exist, just redirect back to the registration page with some error variable on $_SESSION or URL/$_REQUEST. That error variable can be used to tell user what's goin wrong. . good luck !
Related
Being a novice with PHP, I may not be taking the correct route with forms but this way works for me, up to a point. Below is an example of my setup/
I have a form at www.foo.com/add.php, which needs an admin to be logged in to the session. The form inserts data into a database. Once it is submitted, the actions is set to action="scripts/add.php" and then that is redirected using a PHP header function to www.foo.com/done.php.
What I want to know is, can you deny access to the script file directly, e.g. if you go to the script file in a web browser it could enter an empty row into the database or possibly cause some other security issues?
If the form is submitted using POST method (with attribute method="post" in <form>), you can still execute your script only on POST requests, by adding this at the top:
if ($_SERVER['REQUEST_METHOD'] != 'POST') {
exit;
}
There are a few options available to you:
Validate the form post data before inserting into the database
Include a nonce or other generated value that is only present in the form prior to submission
The problem you're trying to solve really sounds like you want to prohibit blank records from being inserted into the database- not necessarily that you want to prevent access to add.php. This is where option #1 comes into play.
In your current add.php, it sounds like there needs to be some input validation. Basically, you'd check the values that are received by the script to make sure they exist. For example, if add.php accepts a first name, as part of a phonebook app, you'd have code similar to the below:
$firstName = '';
if(isset($_GET['firstName']))
$firstName = $isset($_GET['firstName']);
// ...
if(trim($firstName) == '')
//do something to handle an error, either set an error flag or die() with an appropriate message
This is a basic example of input validation, PHP has a validation library you may want to become familiar with: http://www.php.net/manual/en/intro.filter.php
With this input validation in place, someone can navigate to add.php and should receive an error. It will also detect if someone submits a blank form as well.
#2 requires that your form receive a unique value when it's generated called a nonce. The nonce is a unique value that's specific to that instance of the form. The subsequent call to add.php will only accept the request if the nonce is valid. An approach might be to store the nonce in the user's session.
Another note outside the scope of the question, since you're inserting data into a database, you should make sure you have proper escaping of inserted data. If you're using MySQL, see here: http://www.php.net/manual/en/mysqli.real-escape-string.php. If using another database engine, you'll want to lookup the specific library to see how to escape the string.
Yuu can try this to check whether request send by post or not
if(isset($_POST)){
continue.......
}
in order to secure such pages i have applied the code below.
Except request method, it also checks that the request comes only from specific domain.
$live_site_regex = '/http:\/\/(w{3}|w*).?yourdomain.ext/';
if($_POST && preg_match($live_site_regex,$_SERVER['HTTP_REFERER']) == 1){
//everything is ok
}
I have a form where a user submits data from various text fields on my webpage to mysql database. Is there any code I can use were it will not let them submit/update the data again? e.g it will redirect them to a page saying sorry wwe have already received your data.
I have a unique number for each user if this helps. any help is appreciated.
Use tokens, it will avoid double submits and CSRFs.
Simply add tokens to an array, $_session most likely, and pop them when used.
Also, disable the submit button with JS after a submit.
You can also set a var in the session user that says he already performed an action, exampled uploaded his picture. Unset it if there is an error in your upload script for instance.
When you receive the post, query the database for the unique user number. If you get back a non-empty result, then display the error. Otherwise, save the data to the database.
The biggest thing you need to determine is what your unique identifier will be. It sounds as though you already have one (you mentioned unique user number?) Your unique identifier could be an email address, or even the full set of submitted data.
There are other ways to emulate this, such as setting a cookie on the user's machine, or disabling the submit button, but, none of these are completely under your control. The user could easily get past them if they tried. Therefore, determining a unique identifier and validating server side is probably the best way to do it.
The answer hugely depends on the reason for which user might send the data twice.
in case of an accident, there is one technique, and all other won't help you even a bit.
in case of intentional duplication the technique is completely different and again there is no general solution - everything depends on the certain scenario.
If you care to explain your certain case, you will get a proper solution.
For the most silly case of pressing "Reload" on a page with post results, you have to redirect browser using Location: HTTP header, e.g.
header("Location: ".$_SERVER['REQUEST_URI']);
exit;
I have a form that the user needs to populate and then the form will be sent to a server.
After the user submits the form, if the server script found that the form is not correctly populated (i.e. the uploading file is too big), it should return error to the client side.
Now, my question is as follows:
How do I keep the user seeing the same page without transferring to a different page?
Because I don't want the user to waste time to reenter everything again. I just want the user to correct the wrong part.
Because I don't want the user to waste
time to reenter everything again. I
just want the user to correct the
wrong part.
This is a good intention, but the wrong solution.
To stay on the same page would mean you have to submit the form using javascript. While possible, why make things more complicated than they have to be?
Instead, submit the form to the server and when you write out the form again to the user with the error message, set what the user entered as the default value on the form. Then it will be there for them and they won't have to type it again.
Note: Don't do this for passwords tho; the page may be cached and then the users password is saved in a plain file on the hard disk. This is why most sites make users retype passwords each time.
You need to show form again and fill previously entered data in input's "value" fields. Of course, don't forget to replace special characters with html entities with htmlentities();
I also found one tutorial for you: http://evolt.org/node/60144
I'm currently developing a page where the user fills out a form, and when submitted they are taken to the next page. When on the next page, I want to have it so that if the user went back to the previous page using the back button, or hit refresh, the submission will not be saved into the DB.
Now I recall reading somewhere that if you had a way to make each submission unique, this issue is averted, but after screwing around for hours on end, for the life of me I cannot recall how this could be done (using PHP), so long story short has anyone ran into this, and if so, what was your solution?
Use the Post/Redirect/Get pattern to avoid this problem. See also Redirect After Post.
Another way is to generate an identifier using uniqid and include it in the form as a hidden input. On submission, store that identifier in a database column marked with a UNIQUE index. This will cause subsequent submissions to throw a SQL error, which your application can handle gracefully.
You can add any confirmation on the second page.
By adding any confirmation box or any button....
by which you can confirm that whether user want to save it or not....
and if you don't want any confirmation...then you can delete the last record....by using managing session...but it is not good practice to fire the query very soon and delete in that kind..
so best way will be by adding any confirmation msg....
Im trying my first form validation with PHP.
I need some guidance with the logic.
I have purchase.php (which has the form) and review-purchase.php(which sets SESSION variables and displays the user data inputted)
If any of the fields fail validation I don't want the user to get to review-purchase.php
Should I be sending the user to the review-purchase.php script, checking validation there and then redirecting back the purchase.php with an error message?
or
should I be using an if/else statement with $_SERVER['php_self'] etc in the form action="" and keep all the validation on the purchase.php page itself and only letting purchase-review run if everything passes validation?
Sorry for the confusing question but i myself am very confused...
That's a question many people ask themselves, and there is probably not one right answer...
What I generally do, in your case, is :
purchase.php displays the form
that form posts on itself (ie, purchase.php)
when data has been submitted, it is dealt with -- still in purchase.php
if there is an error (like something not OK in the input), you can re-display the form really easily, this way : you already have every values that were typed in by the user
if there is no error, you can do whatever you have to with the data ; like set it in session, if that's what you need, or save it to database, for instance.
only when everything was OK (data validation OK and storage OK), you redirect to "confirm.php"
that confirmation page does nothing except display a message saying "thanks for your purchase", or something like that.
It means putting more stuff in your purchase.php, yes :
(re-)displaying of the form
dealing with the input
But, this way, it is really easier to re-display the form, pre-filled with what the use first typed, when there's a validation error.
You can use functions/classes/methods or even some included files, though, to not end up with one big chunk of un-readable / un-maintenable code...
If your form posts to another page, it'll be really harder to re-display the form... If you are using redirections, you'll to pass everything in the URL, and it'll be a mess (And there's a size limit, too)
Here, it means I would totaly remove your review-purchase.php file ; and transform it to a confirmation page, so the user knows everything was OK and his purchase is being take care of.
I suppose it's quite what you meant in your last paragraph, actually :-)
Just beware : you have to think about escaping data before injecting it back into the form (see htmlspecialchars and/or htmlentities) ; that is true for everything you get from the user (And, probably, for PHP_SELF too, I'd say) ;-)
Well, it seems you have a misconception about where and when PHP code is executed. If you want to validate user input on the server side - with PHP (and you should because any JavaScript validation on the client can be worked around by a nefarious user) - the PHP validation can only occur after the user has posted data. That is no matter to which page the user posts the data - be it the original form or a different page.
So, in your situation if you want users to go to a page if validation is successful and to a different page is validation fails yo will need to do a redirect anyway.
In this case you have two paths:
user requests Purchase.php and fills out the form
user posts data to validation page
if data is valid -> display purchase review information
else -> re-display form page and have user re-enter data
So if Purchase.php posts to itself, you can validate there and redirect to review.php only if data is valid. Which means that in the successful case you do 2 redirects and in the failed case you do only 1 post.
On the other hand, if you post directly to review.php and you validate there, you have 1 post in the successful case, and 2 in the failed case.
The above is true no matter how you spin it - unless you use the same URL for the form and the review, in which case you can put logic in the same place to do the form, validation and purchase review in the successful case.
I hope this helps.
The most common way of doing this would be to do all your validation checks in purchase.php. This way, if there are validation errors, it's easier to re-display the form with all of the information that the user has already entered.
If the validation passes, you can do a redirect to review-purchase.php with the necessary purchase information set in a database, or possibly $_SESSION if you're not using a database.
If you can separate the validation code into functions, and the display code into templates to be included, you can achieve a nice separation of logic that would allow you to use them from whichever file you go with. You might be able to avoid a redirect in that way, ie. in purchase.php you could check if there's $_POST input, validate it, and either re-display the form template, or display the purchase review template.