I've been reading PHP form handling tutorials, and they suggest using a hidden field in the form so PHP can use something like IF ($_POST['hidden_field'] == whatever to detect whether the form was submitted or only displayed.
But after getting XDebug working with Notepad++ and stepping through the code and observing the variables, it's not clear to me why we can't just go IF ($_POST['submit_button'] == 'Ok') and do away with the hidden field entirely.
After all, there doesn't seem to be a time when the hidden field is set without the other form fields being set too (even if they're empty). The first time through, when the form is being displayed and before it has been submitted, the $_POST variable already exists, but it is empty. I suppose we could also use IF (!empty($_POST)) to see if the form has been submitted?
Is there a special case I'm missing where the hidden field is necessary to detect form submission?
EDIT: Ok, the special case I was missing and that requires the hidden field appears to be this. http://www.vbforums.com/showthread.php?562749-PHP-Checking-if-a-form-has-been-submitted-the-correct-way It seems that if you hit Enter to submit the form, the $_POST variable will not include the value of the submit button. Chrome doesn't seem to behave that way but maybe other browsers do.
Is there a special case I'm missing where the hidden field is
necessary to detect form submission?
To detect the form submission you don't need a hidden field in the form but some times it's used as a spam protection. For example, if you put a hidden field in your form, like
<input type="text" name="humans" id="humans" class="humans" />
You may use a css class to hide the filed like
.humans { display: none; }
and when you check the form submission, you may also check if the field is empty or not, like
if(!empty($_POST['humans'])) {
// it's spam
}
else {
// it's human
}
Because, bots/spammers (using automated script) can submit the form and basically the script tries to fill up all the fields and doesn't know about the hidden field that you have put to catch it and this way you may determine whether it's submitted by a human or bot. You may read this article for more information and better understanding of spam blocking..
No, you have the right idea.
I wouldn't recommend doing this, however - sounds like whoever wrote the tutorial is a bit of a newbie. ;) If you're using POSTs for your forms already, I'd stick with the more traditional (and simpler) method of detecting whether the form was submitted or if someone is just viewing the page by means of the HTTP method ($_SERVER['REQUEST_METHOD'], as "GET" or "POST" in PHP).
Why implement a [hidden] field to check if the form is submitted when you must have other fields to check by if you have a form in the first place.
Other than checking if submitted, the hidden field is redundant, and so just pointless extra code.
If you have multiple forms on a page, name the submit button, if only one, just check if $_POST isset(), then go about validating data, etc etc
You can use !empty($_POST) instead, but I try to avoid this (depending on scenario) as I like to tell the user they did not enter anything, otherwise user clicks submit and it just hows them the blank form again.
Sure they would likely know they're messing around, but perhaps they thought they typed something, for numerous potential reasons.
Always good to keep users appraised, especially of any potential mistakes on their part.
There is no difference in using a hidden field just to check that the form has been submitted.
But let's say you want to dynamically post a value that there is no reason to show in the form.
For example you have an array $user that holds all the data of a user. The user submits the form, and you pass as a hidden field $user['id'] to work with their id after the submission.
Or you find their language through IP or whatever and pass it as a hidden field to show a message in their language.
Although I don't do this myself, I would say that it can be useful to undermine curl or other methods of accessing the site outside of a regular browser - of course the hidden field has to differ with every request.
Yes, there are multiple use of hidden field to validate a submit
as you mentioned, differentiating between form view and submission.
as #kingkero mentioned, a way to block form auto submissions by robots.
and in case of editing an existing record
a primary key is required to locate original record, and it should be hidden so user can't change it
you can save old data somewhere in server side before sending to browser and then send a reference key to that data as hidden field, later it can be used to compare old and new data to determine what has been changed.
in multi-user system, if more then one user select to edit and save a specific record at the same time then there is chance that they can overwrite each-other!! to prevent this situation a hidden field can be used to determine and notify user if selected record has been changed during form load and submit period.
Related
I have a problem with a system called OSTicket. You simply can't remove the "required" status of the input field (email) when you are adding a new user to your database. That's because the dynamic form / input fields are set with Ajax and we can't access those files. Therefore, I have to get a workaround for this. I tried using Javacript / jQuery so that it puts a default value in to the HTML, but that didn't work. With other words: I do not have access to the form that I want to edit, therefore I have to manipulate it on a different way. This is a known issue btw; OSTicket works this way.
Anyhow, in the backend, I can change the validator from email to for example: regex field. So I thought: maybe I can check the field by using a regular expression and checking whether the field is empty... well: no result. If you submit the form, it still gives you the error "field is required, please fill in".
When I check the Ajax response, I see this: http:// mydomainname.com /scp/ajax.php/users/lookup/form
Problem: ajax.php exists, but there is no /users/lookup/form. And when you check ajax.php, it's written like this:
url('^/orgs', patterns('ajax.orgs.php:OrgsAjaxAPI')....
So to wrap it up... I tried:
Changing the HTML (removing the required status)
Manipulating the DOM via jQuery / Javascript
Changing the field from an email field to a regex field and checking if empty
Now, I think that I have to do something to manipulate the Ajax call (if possible), but I don't know where to start. What is the best way to do this?
I mean, is there a chance I can bypass a required field, without filling in something or is there any other way I can remove the required status of that field after the form has been loaded and I submit the form?
Problem
I am developing an application (in PHP) in which, I will show the user a report of some derived values based on previous entries he had done and the user will check for correctness - if correct, then the user can press Save button to submit it to database. Otherwise, the user should be able to edit previous entries, but he should not be able to change derived values in that report.
For that purpose, I have enclosed these values in a hidden input field, so a normal user can not alter these values, but if web developers could inspect the element in their browser and change these values.
Can we prevent these type of attack? If so, how?
My thoughts
I can make a string of all hidden fields, encrypt it and save in another hidden field - after postback I can cross-verify actual value and encrypted value.
Is this the correct way to achieve this? and how to do this
What do you think?
It's very hard to get a good idea of what you are trying to do but perhaps a solution could be to display a form with input fields disabled (http://www.w3schools.com/tags/att_input_disabled.asp) then have at the bottom of your page e.g. Is this information correct? .. Then 1 option to Save, and one option for No/Edit. Then do an if(isset($_POST['edit'])) { .. run form again but with input fields not disabled }
Only have your SQL update code in the 'edit' section of the code, and have a seperate SQL update code for the save section which just moves the values from wherever you are grabbing them from, to wherever they need to be.
Hope that helps.
If there are derived values that you need to fill out your form, but don't want to use hidden fields - I suggest using session variables that would contain those derived values as needed. Depending on how many of these forms there are, and how many users will be using them - the overhead is usually negligible with this number of fields (in the 30s)... if you discard them when not needed of course.
I've got a populated table which admins can edit and a submit button to apply all the changes made but I was wondering if I could narrow it down to only the ones they changed? I don't mind having an extra checkbox to specify whether it requires updating or not which the user can check but I don't know how to send ONLY those parts of the form to $_POST.
Thanks in advance.
The entire form will be posted by default.
To do what you want to do you can of course go the Javascript way.
Making users click on e.g. a checkbox for the records they have changed wouldn't be the preferred way IMO.
You could use JavaScript to note the changes, update a hidden field and post these instead.
You could also add the current values to the session and then check on submission which ones have changed by comparing the session values to the post values.
Using PHP; is there a way to check what type of form field was used to enter info in a form.
For example: was it submitted via a list/menu, radio button, text field, textarea, or checkbox.
I have this info stored in the database; but I'm trying to see if there is a way to do it without querying the database or using hidden form fields to pass the field type. Basically is there a function that already does this?
I don't know of one though I'm sure someone else might pop up with an answer. But if the forms in question are of your own design you could name the inputs as checkbox_ or textarea_ prepended to your normal name. Then parse them on the form processing side.
The data entered into a form will be submitted as a set of key:value pairs only.
With standard HTML form elements only there is no way of telling what type of form field was used to gather a particular value.
Only name/value pairs are passed through the Post data, so you would need to mark it in the field name to give your server script a hint of what it is. You could do this with a prefix/postfix. Depending on where you are in your project, you may want to look into using a framework and taking advantage of the advanced form handling options that they can give you.
Currently, when I design my forms, I like to keep the name of the submit button equal to the id of the form. Then, in my php, I just do if(isset($_POST['submitName'])) in order to check if a form has been submitted and which form has been submitted.
Firstly, are there any security problems or design flaws with this method?
One problem I have encountered is when I wish to overlay my forms with javascript in order to provide faster validation to the user. For example, whilst I obviously need to retain server side validation, it is more convenient for the user if an error message is displayed inline, upon blurring an input. Additionally, it would be good to provide entire form validation, upon clicking the submit button.
Therefore, when the user clicks on the form's submit button, I am stopping the default action, doing my validation, and then attempting to renable the traditional submit functionality, if the validation passes. In order to do this, I am using the form.submit() method but, unfortunately, this doesn't send the submit button variable (as it should be as form.submit() can be called without any button being clicked). This means my PHP script fails to detect that the form has been submitted.
What is the correct way to work around this? It seems like the standard solution is to add a hidden field into the form, upon passing validation, which has the name of form's id. Then when form.submit() is called, this is passed along in place of the submit button. However, this solution seems very ungraceful to me and so I am wondering whether I should:
a) Use an alternative method to detect which form has been submitted which doesn't rely rely on passing the submit button. If so what alternative is there? Obviously, just having an extra hidden field from the start isn't any better.
b) Use an alternative Javascript solution which allows me to retain my non-Javascript design. For example, is there an alternative to form.submit() which allows me to pass in extra data?
c) Suck it up and just insert a hidden field using Javascript.
UPDATE:
I've accepted the correct answer but I just wanted to clarify my mistake here so it would be more helpful for others. I use Mootools and I very naively believed that when I used addEvent('submit' ...) I needed to immediately call event.stop() in order to prevent the from from being submitted. Actually this is not the case and I can just call event.stop() only if validation fails. Otherwise, the default submit gets fired, as usual, and using form.submit() becomes completely unnecessary.
You could send the forms to different handlers with action=file1.php and action=file2.php.
Are they processed using a bunch of the same code? Put that into separate files, include the commonalities, and write the unique bits in each of the handling files. Don't hack, organize.
For Javascript validation, don't halt the default action then resume, instead do this:
if (validation != valid) {
return false;
}
That way if JS is turned off or the validation fails, the form action/event is intact and it behaves as expected, otherwise it bonks. And certainly, certainly retain server-side validation. That's the "real" validation, the client-side is only to please the user and save them time. Never rely on it for YOUR sake.
You can customize the action of the form to add a get key/value; such as action="formhandle.php?formid=10"