what are the possible usage of hiddden field control of VWD in asp.net page
Hidden input fields could be added to a form in order to pass some value when the form is submitted that the user doesn't see and cannot modify using the application interface. They could be useful when you want to persist some values across multiple requests. It's true that in a standard ASP.NET WebForms application their value is quite limited as you already have hidden values holding the View State allowing you to persist values across requests.
Hidden fields can be used to transfer data back to the server from the front-end and also sending data from server to browser. For e.g. you've written a javascript function that needs to do something if the value of a field is x, then you can always create a hidden field and set its value from server; your javascript can pick the value from this and do whatever it wants to do. It's just like a normal text field, the only difference is that it isn't visible on the page.
Asp.Net internally uses hidden fields to send view state data too. When your .aspx page has been rendered, view its source and you'll see asp.net has automatically created a few hidden fields for its own use.
In Asp.Net architecture it is used as 1 of the 8 (client-side) State Management mechanisms.
Related
I have been writing a bunch of generic ASP.NET controls, and one thing I can't seem to wrap my mind around is when to store values in viewstate, and when to assume it's OK not to.
On one hand, it makes sense to store the entire state of the control in viewstate, including properties like:
Text box values entered by the user (or any form data)
Configuration options like height or page size
Even how the control has been composed - for example storing all the data a grid view is built from, or the grid itself.
Ignoring performance, the more you can shove in viewstate the better, because it means the control will behave exactly the same across postbacks and never "accidentally" revert a value or "forget" it was disabled. But viewstate is not free. Storing everything means the control will now output both the HTML and all its internal properties to create that HTML, which would almost always more than double the output.
My question is not about performance, but about strategy. On what criteria do I decide to put a property in viewstate? I was thinking something along these lines:
If the user can't change a property, then the server will always set it explicitly, so it's OK to leave it out of viewstate. Even for something like color=red, the user doesn't set this property directly; they will click a button elsewhere which indirectly sets this property. That button or its owner should keep the state, not the control that renders the color red.
This logic implies that the only properties that should go into viewstate would be:
Form elements like <input> (and with Request.Form[c.UniqueID] this can be avoided still)
Properties that the user can control interactively directly on the control.
Does this logic make sense? It seems weak and I'd like to hear more from experts.
Use ViewState for things that are not necessary for your control to work.
Use ControlState for things that are necessary for your control to work even if ViewState is disabled.
The initial values and the control hierarchy(even html-controls) are compiled into Temporary ASP.NET Files when the page is first requested. So they don't need to be stored anywhere when they are never changed (and even ViewState will not save them).
A control does only store properties in ViewState which have changed during the page's life-cycle(since TrackViewState). A control which state was changed is "dirty". For example if you change TextBox1.Text in page_load, ViewState.IsItemDirty("TextBox1.Text") would return true. These values will be stored in ViewState.
Look here and here. (I really recommend to read both articles)
Control State vs. View State Example
Check this article on MSDN covering when, where and what to use the plethora of state management options available in ASP.NET the view state section is posted below for convenience - checking your requirements against the advantages and disadvantages should guide you on usage on a case by case basis:
Whole article here: http://msdn.microsoft.com/en-us/library/z1hkazw7(v=vs.100).aspx
Viewstate Excerpt:
View State
Web Forms pages provide the ViewState property as a built-in structure
for automatically retaining values between multiple requests for the
same page. View state is maintained as a hidden field in the page. For
more information, see ASP.NET State Management Overview.
You can use view state to store your own page-specific values across
round trips when the page posts back to itself. For example, if your
application is maintaining user-specific information — that is,
information that is used in the page but is not necessarily part of
any control — you can store it in view state.
Advantages of using view state are:
No server resources are required The view state is contained in a
structure within the page code.
Simple implementation View state does not require any custom
programming to use. It is on by default to maintain state data on
controls.
Enhanced security features The values in view state are hashed,
compressed, and encoded for Unicode implementations, which provides
more security than using hidden fields.
Disadvantages of using view state are:
Performance considerations Because the view state is stored in the
page itself, storing large values can cause the page to slow down when
users display it and when they post it. This is especially relevant
for mobile devices, where bandwidth is often a limitation.
Device limitations Mobile devices might not have the memory capacity
to store a large amount of view-state data.
Potential security risks The view state is stored in one or more
hidden fields on the page. Although view state stores data in a hashed
format, it can still be tampered with. The information in the hidden
field can be seen if the page output source is viewed directly,
creating a potential security issue. For more information, see ASP.NET
Web Application Security and Basic Security Practices for Web
Applications.
I think you're right to be concerned about viewstate bloat, but what other options are available to you? If you don't store your variable data there, where will you put it? (You may wish to consider removing some configuration items- perhaps not let the user change so many properties).
I have a web page and a modal dialog page. On clicking the save button in the show modal dialog. closes the window and returns a value. Now when the
control reaches the JavaScript function of the parent window . I wnt to perform some database operation on the basis of this returned ID.
I am using the following approach to utilize this returned value.
Keeping it in the hidden field and populating the returned value in hidden control.
keeping a hidden button in the parent window, performing the click event when control comes back to JavaScript function of the parent page. Thus in the server side button handler get the value from hidden field and perform database operation on the basis of returned value.
Is this approach fine. Or I can get rid of hidden field
That's not terribly bad provided the ID returned is not sensitive information that someone can use to modify a record that doesn't belong to him. One can perfectly manipulate this ID on the client side for any other ID and have your logic update a different record from what you intended.
If all you are doing is calling a server side method passing this ID; why don't you do the whole update from the pop-window itself (at that point you already know the ID)?
If the parent window (page) is meant to be updated; you can just perform a normal refresh of the page (ie. use window.location to redirect the user to the same page so he can see the update or use Response.Redirect to the same page.)
What you're probably looking for is called AJAX. With AJAX you can communicate with your web server from within your JavaScript code directly. No HTML form posts are required then. You might want to look at frameworks like JQuery. These have easy implementations (cross browser wrappers) to send HTTP requests via AJAX.
Note: I just noticed, you are using ASP.NET. Take a look at ASP.Net AJAX Page Methods.
This is a clarification question: I'm studying for MCTS 70-515 and in my training kit it states that Hidden Fields: "users can view or modify data stored in hidden fields"
Now I'm aware that users can view the source of the page and then that would display the hidden field data. But I'm curious as to the modification part. How would a user modify a hidden field data and how would it affect the site? Even if they modify the data via View Source they can't save the page and then post the data back to the server.
What am I missing that the author is assuming I know?
OK well all the answers said the same thing (at this time). I guess if the author would of said "savvy" user then that might of tipped me off. I guess I've always assumed that users wouldn't know of Firebug or any other tool that can do manipulation after the page has been displayed to the user.
Thank you for all your answers. I appreciate it!
The hidden field is just a key-value-pair represented as a key-value-pair when serialized and sent to the server, just like any other form element. There are a number of ways to modify hidden fields - one is to use FireBug or some other "developer console" in the browser, another is to manually write the request and send it to the server.
In addition to using a debugging tool such as Firebug, the user could change the value of a hidden field indirectly though other interactions (with JavaScript) making the change for them. Normally, the user would be unaware of the technical detail of what they are doing (they neither know about, nor care about the fact a hidden field got changed)
Other tools, such as Fiddler, may intercept the web request and change the value of the hidden (or any) field as it is being transfered to the server on a postback.
It is possible to change the value of a hidden field on the server during a postback, as you know, or on the client using JavaScript.
Example using jQuery: http://jsfiddle.net/JGsQ5/
Once the page has been loaded by the browser, it is stored in the DOM (http://en.wikipedia.org/wiki/Document_Object_Model) which is what JavaScript manipulates and is used by the browser to build a HTTP request which is sent back to the server as a postback.
Easy, open up a program like FireBug and change the element value. Remember, markup is client side, so the server is trusting the client to send back the right data -- however, this is easily circumvented.
It is best to store data that is essential to the security of your application in session's, whereas the data remains on the server side and is tied to the client. ASP.NET can make up of hashes to prevent the unauthorized modification of fields, amoung other things.
How can we take decision for viewstate and hidden field in ASP.NET.
In my case i am using page cross post back and by using public properties of first page i am accessing them in second aspx page.
After getting public variable in second aspx page i need to access those value in second page but as soon as i do postback in second page, i am not able to find those value.
Hence to solve this issue i have two solution either use viewstate in second page or using hidden field in second page.
I am not able to decide which one should i use?
The approach is quite the same. Only difference should be the size of stored info (viewstate is using [sometimes encrypted] base64 while hidden fields use plain text unless you encode them yourself), and viewstate allows you to make sure the data was not tampered with thanks to the default validation it has in place.
If the data is small and you want to manipulate the value based on some client-side behaviour, hidden field will be useful.
Difference between view state and a hidden field in asp.net
http://royalarun.blogspot.in/2012/03/difference-between-view-state-and.html
Both are used to store the value during the postback in asp.net , but
In View state - not able to change the value by Client side code i.e java script.
Hidden field - possible to change value by Client side code.
In View state - You can store more than one value like Datatable and Dataset
Hidden field - You can store more than one value in hidden field,by serialized it.
View state data is encrypted and Hidden field is not encrypted
I have a custom made ASP control which is based on a select (drop down menu). If I disable my control by adding the word "disabled" in its html, I start getting null pointer errors when processing the form data.
I figure, either the browser doesn't post back disabled form items or ASP.NET ignores them when processing the form data. I'm not sure which one it is. I'm trying to understand where I'm loosing data.
Thanks for your help.
PS. I realize that there are better way to create and disable controls than manually editing html but there's a context here that doesn't allow me to do otherwise.
Yes setting control's Enable = false is prevents control's value to be added posted data collection.
you can use readonly attribute instead.
here in MSDN it says :
The Text value of a TextBox control
with the ReadOnly property set to true
is sent to the server when a postback
occurs, but the server does no
processing for a read-only text box.
This prevents a malicious user from
changing a Text value that is
read-only. The value of the Text
property is preserved in the view
state between postbacks unless
modified by server-side code.
Also here is the Microsoft's reply to a bug report related to topic.
but if you use in classical way like that it will work :
txt2.Attributes.Add("readonly", "readonly");
It will prevent the control from posting back but remember this web paradigm is a client/server technology. A person could modify the client data (HTML and / or Javascript) and force a postback no matter what you send him.
Therefore don't rely on this for security sensitive operations such as money manipulation and so on.
Always do a check on the server-side too for sensitive operations.