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.
Related
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 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.
I'm a bit rusty in PHP,
I'm curently doing an PHP assignment where a user can select and save listed images/data/values into their own collection.
I have inputted all the data and printed it out in a repeat region with recordset paging.
I'm confused about how I am supposed to save a checked checkbox temporary before submission as there a more then 1 page as I'm using recordset paging to output the options.(Meaning: i have selected 2 values in the first page then i click next page to select balance values and finally submit my selection)
TIA
I have read an article on storing in session , that is the solution I guess, but I wonder how I'm supposed to send the value to the session when chaging the page (recordset paging generated by Dreamweaver)
To clarify the previous answers, you will most likely want to create a new $_SESSION variable for each check-box and associate a boolean with it.
You can store the result of a form post in PHP's $_SESSION variable.
Read this post for more information: Storing Form Data as a Session Variable
Also, there has to a tutorial or something in Google Land.
If you need to save the form results without submitting the form, try a JavaScript/AJAX approach. The idea is that you actually do submit the form, but in a behind-the-scenes kind of way (that is, the user never notices it). Essentially, you're going to want to build a "autosave" functionality. Look at these two posts:
Autosaving Form Input Using Prototype and PHP
AJAX Autosave functionality
They probably won't fit your needs exactly, but they should give you a good idea of what you should do.
Note: both of these posts use a timer to trigger their autosave functionality. I would suggest tweaking the trigger to detect any changes in your form instead.
Store them in _SESSION and process when needed.
We have an edit form:we populate it with a variable number of checkboxes (it all depends,let's say, on how many pictures we have on the article we're about to edit).
All the checkboxes are per default "checked" and if nothing happens the data associated(our pictures in this case) remains untouched.
Altough if we uncheck one we actually want to not keep the picture in our edited post and delete it from our database.
I know unchecked checkboxes dont get Posted,and that I have one work-around:
place right before the checkbox an hidden field with the same name..in this way with the checkbox unchecked can still post the hidden input.
but i have this situation:
/*i'm querying the database to load all the article's data and I check if */
/* there's any picture so I build, with a while loop, an associated checkbox*/
<input type="checkbox" name="picture[]" value="$row['pic_id]"/>$row['pic_name']
When I submit our edit form I check if there's any data inside our array picture and if positive i want to delete it from database.
Now if I simply add an hidden field at the top of each checkbox (so same name and same value..cause it's the value i need to use in the next query) I fall into the problem:
how to distinguish if the posted data comes from the actual checkbox (if eventually checked) or from the hidden input??
thanks again
Luca
Why don't you check it on the server side?
You know what was the original list, you have your new list. Those that are not in the new list, but were in the original list, should be deleted.
So you don't need to add any javascript hacks, or hidden inputs.
On the server side you can use the following approach:
$array_of_ids_to_delete=array_diff($array_with_all_ids, $posted_ids);
The $array_with_all_ids must be already available, because I guess you use it to output all the checkboxes. $posted_ids represents your picture[] array.
After that you only have to run a foreach on $array_of_ids_to_delete and get rid of those images.
I want to do a search with pagination, but I don't know how to 'store' the data in the $_POST array, should I do it with sessions?
Rolensen
If you are doing a search, you are trying to GET data from the server, and not send data to it -- which means you probably should use GET, and not POST.
Also, it would allow your users to bookmark the result pages (or send those links by e-mail, IM, ...), which is always nice ; and, also, use the back/forward buttons of the browser without getting an alert box, which is nice too ^^
(Oh, and, BTW, it would help solve your problem ;-) )
Yes, you can use sessions or hidden fields and even better GET method in your form.
It is possible to use both GET and POST in form, just add appropriate attribute method to form tag:
<form action="index.php?page=5" method="POST">
So the pager links are submit buttons while rest of the data is stored in hidden fields. But that's not a good way to do this because you cannot pass someone link (on IM for example) to your search results.
But the best way is to store somewhere POST input data (look here: http://www.symfony-project.org/plugins/, when you input your query once, it is stored and remembered so you dont need to fill form multiple times)