According to MSDN and the MCTS self-paced training, asp.net can use Hidden fields for client-side state management. The book material goes on to say view-state is more secure than hidden fields because the data is encrypted.
I must be missing something here. I setup a Label and made it hidden. I can store data in this hidden label and it won't even be sent to the client browser. This not only works like server side state (note the runat=server), but this seems more secure than view-state because there's no need for encryption as the client can't even see the field.
<asp:Label ID="Label1" Visible="false" runat="server">secret info</asp:Label>
Contrast this with an HTML input field. Here, the client state info makes sense.
<input id="Text2" type="text" style="visibility:hidden;" value="secret 99" />
So what's the deal?
When you create a label in .net and set it's visibility to Hidden, it does not render to the client and its data is stored in viewstate.
Therefore, it is not "more" secure than viewstate as it is using viewstate to maintain the data.
Regarding hidden fields, there are four kinds: First up is the regular HTML one which is simply an input of type hidden. This has no visible rendering although it is in the html. It also has no viewstate properties. It is declared as:
<input id="MyId" type='hidden' value='whatever' />
The second one is a regular input with a css property marking it as hidden: If CSS is disabled or otherwise overriden then the control would be visible to the user. Other than that its pretty close to the same thing as a type='hidden'.
<input id='MyId' type='text' value='whatever' style='visibility:hidden' />
The third one is the .Net hidden field. This does has viewstate storage, but it also causes a regular hidden field to be generated in the html.
<asp:HiddenField id='MyId' runat='server' value='whatever' />
And, the fourth one is a regular .net text box that is marked as not-visible.
<asp:TextBox id='MyId' runat='server' Text='whatever' Visible='False' />
The .net ones will cause data to be placed in viewstate. The HTML ones do not. If you set Visible=False on a .Net control then it is not rendered to the client however it's data is typically stored in viewstate.
There are other ways of throwing data into the page, but they are derivations of the above.
Generally speaking if you have a value that your javascript code needs but you don't need to display it to the client then you use a hidden field (html or .net). If you have a secret value then typically you don't want this to go to the client side if at all possible. And that means even keeping it out of viewstate. As a side note, don't depend on viewstate "security' there are tools out there which will easily decrypt it.
A field which is not displayed is not a hidden field (even though it is "hidden").
Hidden fields are <input type="hidden" name="somename" value="somevalue" /> fields. And those can be manipulated by users.
Related
Should I use ASP elements with a runat="server" attribute or an HTML form?
It seems like using ASP tags such as <asp:TextBox> is much more comfortable since I don't have to redirect the user to another page on a form submition, but also from what I've seen, it seemed like HTML forms are the more accepted way. I was starting to wonder if using ASP elements increases server load or has any other disadvantage?
In case I should use ASP elements, how do I validate the input with Javascript before sending it to the server?
In case I should use HTML forms, how do I not redirect the user on submition and also not run the server code on page load?
You can easily use the HTML5 input type in Web Forms by adding the runat="server" attribute, so that it can be accessed on the server-side:
<label for="name">Name:</label>
<input type="text" id="name" name="name" required
minlength="4" maxlength="8" size="10" runat="server">
Note, on the server-side you will access it via the Value property of the input element, not with the Text property of a typical ASP.NET textbox control.
Contrary to what a lot of people think, ViewState only ever becomes a problem when people do silly things like nesting data-bound controls, in which case it can become bloated very quickly.
Not sure what you're asking regarding validation... but you still have options like this on both client and server. If you're working with an existing Web Forms project, I would stick with regular ASP.NET controls and keep it simple. This way, you can have out-of-the-box validation on both client and server.
I am using latest DevEx Asp.net controls. In one of my pages, I have a form with AspxLabels and AspxTextBoxes. In certain textboxes I have a required field validation. I also have 2 check boxes on the page when clicked they populate certain textboxes with data from server.
Here is when the problem occurs.
When any of the check boxes are clicked, I make all textboxes that would be populated from server set to empty string. Then I set the data.
If one of the required fields already has some data, then setting it to empty string when checkbox is checked causes client side validation to kick in and server call to get the data is not done.
Does anyone have any idea how to approach and solve this problem?
Based on your description (aspx would make it more clear) you should set ValidationSettings.ValidateOnLeave to false and validate editor manually.
Here is sample from devex code central article:
<input type="button" value="Validate" onclick="tbTextBox2.Validate();" />
<dx:ASPxTextBox ID="tbTextBox2" runat="server" ClientInstanceName="tbTextBox2">
<ValidationSettings ValidateOnLeave="False">
<RequiredField IsRequired="True" ErrorText="Field is required." />
</ValidationSettings>
</dx:ASPxTextBox>
For various ways of validating form editor(s) on client side read How to raise validation on the client side.
I'm working on an application which generates a list of customers from a db. I have disabled ViewState in default.aspx, but now when I viewed the source code of the generated HTML page I saw that the ViewState is on.
I've tried to add both ViewStateMode="Disabled" and EnableViewState="False" (separately and even together) without any luck.
What can be wrong?
ViewState code from the source code if it helps:
<div class="aspNetHidden">
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="88luWaDvrTt0+OWLhB and a lots of characters after this...
EDIT: Now when I looked again in the source code I can see the following which I find strange:
There's A LOT of ViewState characters (takes 15-20 seconds to scroll through it)
There's two places with ViewState code, separate from each other
ASP.Net pages have both Control State and View State. Control State is for absolutely critical data that the control can't function without (at least in theory).
View State and Control State are both stored in the same field. A site with View State completely disabled may still have Control State.
Unfortunately, ASP.Net is quite inconsistent as to how it differentiates between the two. For example, a DropDownList will no longer fire change events with View State disabled. I consider that a critical function of a drop down and I would be happy to spend the few bytes of space to store the currently selected value in Control State so that a change could be detected.
If you are wondering about the contents of the hidden field containing state, you can decode it. It can be very useful for detecting View State "leaks".
Looking at the MSDN documentation, even when you disable it, it is still used to detect postbacks:
Even if EnableViewState is false, the page might contain a hidden view
state field that is used by ASP.NET to detect a postback.
You can deserialize the viewstate to see who's putting data in there:
LosFormatter lf = new LosFormatter();
object deserialized = lf.Deserialize("!!! YOUR VIEWSTATE HERE !!!");
Attach a debugger and have a look at the contents of deserialized
From my page's code-behind I want to access the value of this hidden field. The value is set properly. I confirmed by checking its value.
<div class="hiddenValues">
<input id="HiddenReportId" type="hidden" />
</div>
From my code behind, I'm using the following to access the above input
string id = Request.Form["HiddenReportId"];
When I run the application this line throws a null exception. Any suggestions ? Thanks!
The input needs to be inside of the form tag (which it may be, can't tell from the code snippet). Also, it needs to have a name attribute:
<div class="hiddenValues">
<input id="HiddenReportId" name="HiddenReportId" type="hidden" />
</div>
Its id attribute may be redundant and isn't necessary if you're not using it. But form elements are identified by their name attributes in a POST.
(It feels a bit unintuitive from an ASP.NET perspective to the uninitiated, I know. ASP.NET convention is to identify everything by an ID, but web browsers use name when crafting a POST. And the web browser knows nothing of the server-side technology being used, it follows HTTP standards instead.)
What is the difference in functionality between
<asp:Button id="button1" Text="Click me" runat="server" OnClick="submitEvent" />
and
<input type="button" id="button1" runat="server" value="Click me" />
Does the input with runat="server" attribute has other or limited properties and methods?
Thank you!
The first one creates a System.Web.UI.WebControls.Button while the second one creates a System.Web.UI.HtmlControls.HtmlInputButton.
Both are server controls, but the controls in the WebControls namespace generally has a bit more functionality than the controls in the HtmlControls namespace. Typically they put some data in ViewState to keep track of their state, and they have server side postback events.
Each controls in the HtmlControls namespace correspond exactly to an HTML element, while the controls in the WebControls namespace may be rendered differently depending on what the browser that is requesting the page can support.
The button represented by <asp:Button runat="server".../> will be converted to a web server control with a rich state model and different properties and methods which has more clear representation in real world like Button.Text = "Click Me".
The button represented by <input type="button" runat="server"..../> will be converted to html server control represented by HtmlInputButton; with has limited properties, methods and events. Most of the properties resemble the html equivalents like Button.Value="Click Me".
Note that elements in a markup page are pre-processed/compiled before being used and will be converted to a class representation where every element is represented by a control. You can access server side controls which are identified by the runat="server" tag from the code behind since they will have the correct matching server control(web/html), other static content including an <input type="button.../> tag with out the runat="server" will be represented as a LiteralControl.
The former line is ASP.NET, the latter simple XHTML.
The former gets parsed and interpreted on the server side, after which the HTML code is generated, which pretty much corresponds to your second example. The ASP.NET Button is really little more than light wrapper over th HTML input button functionality, and should be used wherever you need to handle the Click event on the server side (or in the general case any events), and is usually the way to go, since you're letting ASP.NET abstract the idea of a button on your page for you.
functionality of both the controls is same with the difference that first one is .net control and second one is html control that can be made servercontrol by using
runat="server".
and first one is rich in evants and metods thn the second one....
There is no server events associated with such a controls, but you can use it in codebehind to change it's properties.
Your second option won't probably even work. runat="server" will be rendered directly to the HTML output where it will have no functionality and will only break HTML validation.
input is an HTML element which has only HTML properties, and definitely no methods of any kind.