I don't see the benefit of having hidden input? If you set the value of the hidden input why not just use that value at the point where you reference this hidden input?
There are reasons for this but I just don't know them.
They're used to pass data that will be needed when the form is submitted. One of the more common cases would be a form allowing users to edit some existing entry. You'll need to know which entry they're editing so that you can update the correct row in the database when they submit the form. The user doesn't need to edit (or even know) the ID of the entry though, so a hidden field works well here.
Other options
URL parameters:
This could also be done by building the parameters into the url that the form is being submitted to:
<form action="save.php?entry_id=1234">
but this means you have to handle building the URL properly and escaping the data yourself, and the length of URLs servers will accept is limited so it may not work for longer data. So generally using hidden form fields is the easier way to go.
Session variables: When the edit page loads you'd store the entry ID in a session variable, and then retrieve it on the page that saves the changes. That's a lot easier to mess up though; setting up and maintaining sessions may require adding code in several different places, and then their session could expire in between loading and saving, and you have to make sure it works if they have multiple windows or tabs open, and you have to make sure it doesn't do weird things when they hit back/forward. Because of all these potential pitfalls it isn't a great way to solve this problem--passing the id with the data being submitted is a lot more robust.
Cookies: In many languages/frameworks sessions are tracked using cookies, so they're basically the same solution. The pitfalls are the same as for session variables even when sessions are tracked by other methods though.
It sends additional information that the user doesn't know or isn't interested in (such as a security token) so that if the form is submitted twice, you can compare the tokens and reject/accept that submission.
Not using hidden inputs means the server needs to keep track of these values instead. This requires the server to keep state, which could otherwise be embedded into the request (form) itself. This may make the page RESTless (not RESTful), i.e. break the self-containedness of an HTTP request. If you did keep track of hidden values on the server, you would at least need to embed a unique token into each form to deal with several different unique submissions of the same form. The cleanest way to embed such a token is, drumroll, through a hidden input. :)
The Hidden Input field is not displayed on the page, so it does not allow visitors to add anything into it. The Hidden Input allows you, the webmaster, to add specific information to a form, to be passed through the form processor along with the data entered by the visitor.
For example, if you have several forms on different pages on your website, you could use a Hidden tag, in each form, that identifies which page the visitor was on when they filled out the form.
The hidden input is for when you want to send information back on a post without the user seeing the data as a UI element.
The web is stateless - ergo, when a POST comes in, you have only a couple pieces of information to determine what you need to do; Session, Url, some ServerVariables, and the Form data passed to you.
If a piece of data is transient that is not useful for putting in the session, sometimes it is prudent to put into a hidden field.
They can also be useful for storing data on the client side for rich internet applications (such as a product Id that is easily accessible to use in ajax calls).
because you have a php while loop with alot of different objects which you can't get the id's of later and you just save them by storing them in the hidden input... also i like them to be a security check to know my users aren't messing with my post variables through tamper data
If you build a tag system like the one here. You can set the values into a a hidden field.
Consider a form that's being displayed to edit a record in a database, one technique is to bake the id of that record in a hidden input and have it submitted back so the server can read it back.
It's also used frequently for security purposes (as genesis has said).
Another reason might be for javascript-oriented scenarios, perhaps for non standard controls such as treeviews, where the concept of a selected node cannot be represented as a normal input. Instead, JS can manipulate a hidden field and store the node's name/id in it, so that it can be read by the server.
It's just what it's name implies, a form input that is hidden from the user. It's a way of getting data to the server that the user doesn't need to see or control directly. This is especially useful for maintaining state.
I'm working on a project right now where a user creates several items that are represented as data objects in JavaScript and serialized when sent to the server. These data items are expressed one way when displayed to the user with HTML, another way as JavaScript, and a third way when sent to the server. A hidden input is the only way to accomplish this. (Okay, fine not actually the only way, but certainly the most reasonable way).
For example, if you have a form to edit an entity from you data model, you could use an hidden input to place the id of the entity you are updating, since you don't want to have this value put in the text input field to be posted back to the server. the hidden field will be posted to the server as if it were part of your form.
All answers explained why we using hidden inputs in form but here is the security concern.
Security concern
Using hidden inputs in forms can be tampered/changed by View source or using developer tools in any browser.
Solution
Use cryptography in your code/project to avoid changing values in
hidden input by attackers/hackers.
Generic Solution
If you want to store any data in hidden input first encrypt the data and store them in hidden input.
When form is submitted then decrypt them if values not change then save your data.
If changed then show some error or else.
Further reading
Cryptography
Wiki Cryptography
For framework Developers
Other framework developers can find cryptography in their framework.
Cryptography in Laravel(PHP)
Cryptography in .Net
Cryptography in Django
As name implies, Hidden fields are similar to other input fields except one difference i.e, hidden fields are not actually shown to the user and hence can not be edited by the user.Its value can only be set at the time of execution i.e. may be form submitting which posts the data to the server.
But the data set on the html page i.e. name/value can be seen in the html source of the page (view source of the page).
We are currently using a generic report which will be used differently by multiple usergroups. We have made this possible by creating linked reports with different settings of hidden parameters (such as 'show column x', 'enable feature y').
These settings (parameters) are needed on other reports as well, so we pass them along using the Go to ... Action.
To create the look and feel we are after, we are passing some additional parameters as well, HTML Viewer commands and Report Server commands such as &rc:Parameters=False (reference).
Unfortunately, this leaves us with only the option Go to URL, since Microsoft hasn't implemented these commands for Go to Report. This means we have to pass our settings (the hidden parameters) along in the URL. This results in a security issue, example given: &PARAMETER_ENABLE_FEATURE_Y=False.
The user might notice this parameter in the URL and is so given the possibility to enable this function by editing the URL to &PARAMETER_ENABLE_FEATURE_Y=True.
So my question is: how to use an Action in Reporting Services while preventing users from editing our sensitive parameters and while being able to use HTML Viewer commands and Report Server commands?
You will never get complete security in this sense if you absolutely have to use URL based parameters.
When navigating via the URL, the only way you can hide parameter values without hard coding them is to make them data driven. In your scenario however this will not be 100% secure as you will still need to pass the value that populates your data driven parameters.
This level of obfuscation is probably enough and can be achieved by collating a list of either every parameter combination or just the ones your need and assigning it an ID that you can call in a dataset. This can obviously still be changed by your users should they get curious and can be a faff to maintain.
I would say your only other option is to hide the URL bar completely by providing a 'landing page' for your reporting and displaying everything in an iframe. This frame can be targeted with a javascript link in your Go To URL:
="javascript:void(window.open('URL to open','iFrame Name'))"
If you are able to though, I would advise you group your users into Active Directory security groups and then maintain a collection of permissions and customisations per group. You can then check which groups a user is a part of using custom code similar to the answers here and return the required parameter values accordingly.
Doing things this way will also enable you to maintain which groups can see what from a central location, assuming you have rolled out the same parameter structure across all reports.
I have a form with text inputs, check boxes, radio buttons, selects and an AsyncFileUpload control.
All of the selects are dynamically populated from the code behind, and one of them has a Select One added (which is removed when another option is selected) from my page controller object.
I have verified that none of the page's javascript is running in conjunction with the upload control other than the script that directly controls the client functionality of the uploader.
If I do not touch any of the other fields and attempt to upload a file I get an Unknown Server Error.
If I change away from the Select One option (which, again, makes the option be removed), I can now upload an image. My solution is to add the option in code behind and remove it once an option is selected from the client, but my question is this:
Why do I get this error? What is the reason for it?
I found the reason. My Select was an asp:DropDownList, and my code was expecting the returned data to be validated. Since I had changed the value from javascript it was no longer the same as what the server had sent, causing the exception I was seeing. The solution is to do those changes from the server instead of on the client. Simple solution to a perplexing issue.
I'm developing a component using joomla 3.0. I'm trying to add forms in my component. I saw that joomla has the JHTML class for adding forms in backend.
what is the recommendation for creating forms in frontend. should I use JHTML or clean html markup ? and where can I find docs for that class.
JForm
JModelForm
JControllerForm
Forms which save data in the databas in Joomla 1.6 + mainly use the JForm package which manages forms (xml or xml strings), fields (the actual fields) and rules (validation).
The normal way simple way to manage it is to extend JModelForm and JControllerForm. If you look in the core you'll see these extended in places you might not expect such as the single contact view but basically that's because those classes provide the basic set up you need to manage a form on any part of your page even if the rest of it has nothing to do with forms.
Alternatively you can always create a new JForm object.
If you have a models folder usually you would have a forms folder and then if needed fields and rules folders. THe latter two contain any custom fields or rules you may need for your extension. These will be found by default when building a form in your extension but if you want them from somewhere else you would need to use addFieldPath or addRulePath or addFormPath as needed in you form xml.
Jform provides a standard set of fields and rules as well as a standard list of filters. Rules means validation while filters will change the saved values. You can also use any filter available in JFilterInput.
If you give a field the same name as a field in the current table object the data will automatically be saved in that field. if you use a fields tag with an name that matches a field by default the fields listed inside the tag will be saves as a JSON string within that field.
That's pretty much the basics, though there is a lot more.
One important thing for me is that if you use JForm the default filtering is very good and you selectively allow html etc so by default it is very secure.
Does anyone know of a browser plugin or application that will save form values then populate the same form when required?
Let me explain what I mean. I'm currently working on the registration page of a web application. As you can imagine it's quite long and I have to keep filling it out. I can fill it out reasonably quickly using values already entered by tabbing through the fields and hitting the down arrow. But, it's not fast enough! Ideally I'd like to enter the form values, then somehow save all the values under a name. E.g. "Valid registration". When I come back to the page I'd like to select my saved "Valid registration" form values and have the whole form populated automatically.
I've tried things like Web Developer but they are no good, they don't populate a form with valid data.
EDIT
I've also looked at autofill forms which is better, but still requires a lot of set up for a long form containing non standard fields.
hi this is Rahul Mandaliya.
some time ago i had faced that problem , and i got the answer , i used RoboFill software for store some data like user name , password and other .
i think you have to download this software.
i have put link for Download is : http://www.roboform.com/dist/RoboForm-Setup.exe
if did not get this software from above link , you have to manually go to www.roboform.com and Download this software.
A colleague pointed out that you can use Selenium IDE for this purpose. It's not really what it's intended for but it works like a charm.
Simply record yourself entering some details on the form, save it as something meaningful (e.g. "RegistrationValid" or "RegistrationInvalidPostcode") then you can run it whenever you like to auto populate the form. The only negative point is that the plugin is Firefox only.
You can download the plugin here: http://seleniumhq.org/download/