I'm using asp.net 4. Every control on a page has its viewstate turned off and in the HTML output, the viewstate looks like this:
< input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"
value="/wEPDwULLTEwNDk4OTMyNTZkZGfL5BMyxxloFnGh0LG4Z2Wef3pPOstqLKsp8DrWelqn" />
When I run this string in a Base64 decoder I see that it's equal to -1049893256. This number changes on every page and every request.
The only controls I'm using are essentially literals; the page is in a master page.
What could this be field represent?
When using webforms, you can never truly turn viewstate off. Just ignore it.
I'd highly suggest you look into the various MVC engines available for asp.net. Those might be more to your liking.
You can delete the the tag of the form from the page,then view the page,the viewstate disappear in the page
second,use template engine,
Related
I'm scraping an asp.net web-form and it always sends viewstates like this:
<input type="hidden" name="__VIEWSTATE" value="/wEXAQUDX19QDwUNZnJtQ291cnNlSW5mbw8GblQKzmHhzYgCAw==">
When I decode it in the View State decoder I get this object: System.Collections.Hashtable.
The precise value of the __VIEWSTATE varies, but it alwasy decodes to the object System.Collections.Hashtable.
What's going on here? Why does the viewstate value vary but always decode to that?
The Page is stateless and so after each postback, it has no idea what happened before. A ViewState is often used in order to persist the information between postbacks. For example, if you selected an option and created a postback, the site might store your option in a ViewState so that your option is still selected after a postback.
What your seeing is the ViewState storing information on what controls are currently rendered on the site (a Hashtable in this case). The values stored in the table may vary, but the control seems to be present between postbacks.
You can read more on ViewStates on MSDN and how/when to use them here.
The goal is to popup an asp.net page from classic asp using post data, however, the asp.net page always has Request.Form variables as empty and shows RequestType get.
I have stripped all the code from asp out, tested receiving the form variables sent from an html page on the asp.net page and this works fine. Copying the same form html to the asp page still gives no request.form data and a RequestType get
<html>
<head></head>
<body>
<form method="post" name="form" action="http://localhost:51307">
<input name="uid" value="1" />
<input type="submit" name="Submit" />
</form>
</body>
The asp site is using frames and the form is sent from a child frame, I'm unsure if this is the issue.
2.
Assuming this worked, I had thought to submit a form in asp and use the onsubmit event of the form to popup the page which would send the form variables as post data. Is this the best way of doing this?
UPDATE
The frames seem to be at fault here somehow, I have posted from the form within the framed page to another classic asp page and then redirected from this to the asp.net page.
This probably happened because "Navigate windows and frames across different domains" is disabled by default in IE browsers, which means you can't pass form data due to security reasons.
ASP.NET requires certain form fields to be set (usually as hidden fields, though HTTP POST obviously does not know the difference) for an inbound request to be treated as valid, thereby populating the relevant variables.
If I recall, you need to set __EVENTTARGET, __EVENTARGUMENT, and __VIEWSTATE.
Then, your ASP.NET code needs to be able to handle what was sent, as the default handlers will expect there to be something in __VIEWSTATE at a minimum. So, you would need to override the ViewState handler in your page. I can update with more information later when I'm at work, since I know I've done this before.
The problem is with the redirect. When you redirect a page, it creates a GET request instead of a POST request, and therefore will not have any form data.
Your options are to :
Append the form values to the query string.
Dynamically generate the form corresponding to the posted Request.Form collection, and submit it to the ASP.NET page using Javascript during the body onload event.
Please see this:
VIEWSTATE" id="_VIEWSTATE" value="/wEPDwUKMTMzMTM1NTAzNA9kFgJmD2QWAgIDD2QWJgIDDw8WBB4LTmF2aWdhdGVVcmwFKGh0dHA6Ly93d3cubGVhcm5kZXZub3cuY29tL1Byb2R1Y3RzLmFzcHgeBFRleHQFCVN1YnNjcmliZWRkAgUPDxYCHwAFHWh0dHA6Ly9vbmxpbmUubGVhcm5kZXZub3cuY29tZGQCBw8PFgIfAAUnaHR0cDovL3d3dy5sZWFybmRldm5vdy5jb20vRGVmYXVsdC5hc3B4ZGQCCQ8PFgIfAAUoaHR0cDovL3d3dy5sZWFybmRldm5vdy5jb20vUHJvZHVjdHMuYXNweGRkAgsPDxYCHwAFJ2h0dHA6Ly93d3cubGVhcm5kZXZub3cuY29tL1NhbXBsZXMuYXNweGRkAg0PDxYCHwAFKWh0dHA6Ly93d3cubGVhcm5kZXZub3cuY29tL3N1YnNjcmliZS5hc3B4ZGQCDw8PFgIfAAUjaHR0cDovL3d3dy5sZWFybmRldm5vdy5jb20vRkFRLmFzcHhkZAIRDw8WAh8ABSxodHRwOi8v........ (it's 10 times bigger but I've removed it)
Is this HTML that ASP.NET produce? And does ASP.NET MVC do the same as well?
That is called ViewState.
ASP.NET MVC does not produce ViewState.
ASP.Net MVC does not produce viewstate, but that doesn't necessarily mean it's faster.
First of all, if you have that much viewstate in an ASP.Net webforms page you're probably doing something wrong. It's not that hard to avoid large viewstates in webforms.
Secondly, the things webforms puts into viewstate mostly substitutes for things mvc pages need to rebuild on each request. This tends to work in mvc's favor on public internet sites, where the bandwidth is both more expensive and slower than using additional server resources. For the private intranet on your company's LAN, it tends to favor webforms where upstream bandwidth from browser to web server is free, plentiful, and fast.
Web forms uses viewstate to maintain control state when you post back to the server. For instance, say you have a text box and a button on a web form. You type something in the text box and click the button. The button performs a post back to the server. When the page reloads, unless you cleared the text box yourself in server-side code, the text box would still contain whatever typed before you clicked the button.
What actually happened was that the data in the text box was stored in the hidden viewstate field and loaded into the text box again upon the page refreshing. The viewstate looks like a jumbled mess because it is base64 encoded. You can store things in the viewstate yourself manually also. In the page_load event of your page just do this:
this.ViewState["someVariable"] = "some value";
Now, if you did this on a blank web form, when you load the page you will see a viewstate field in the html like the one you pasted (except a lot smaller). If you copied the value from that hidden field and pasted it into a viewstate decoder (like this one) you would see someVariable with a value of "some value".
Now put a button on the form and in the button's click even do this:
Response.Write(this.ViewState["someVariable"].ToString());
You will see "some value" written out on the page. What you did was manually store something in the viewstate, it got rendered to the page in that hidden field, then that hidden field got posted back to the server and you read from it to display the data.
This is the primary functionality of web forms. MVC does not use viewstate. MVC relies on another technique known as model binding which would be out of the scope of your question. Google "asp.net mvc model binding" for more information on the way mvc maintains information across posts.
Slightly off-topic example of a viewstate joke:
I have a rather large community site called U413. I recently redesigned it to use ASP.net MVC 2.0. It's a community for programmers and they razz me all the time for using webforms. Well now that it doesn't use webforms I decided to play a little joke on them. MVC does not use viewstate but I went into a webform and generated a viewstate that contained some data and manually pasted the hidden field into my view in my MVC app.
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTE2MTY2ODcyMjkPFgIeE1U0MTNTZWNyZXRBY2Nlc3NLZXkFM2h0dHA6Ly93d3cudTQxMy5jb20vQ29udGVudC9VNDEzU2VjcmV0QWNjZXNzS2V5LmpwZ2RkpshYUvbSiUuE0YaYNBH0rvTGj4qEcquSqQeUs9ZpuIQ=" />
Already several people have gone snooping through the html source hoping to find little secrets or exploits and encountered this. They immediately decoded it and got a good laugh. Copy the value and paste it into the decoder I linked to earlier if you want to see.
I am working in a CMS where we use tokens ( which is turned into a user control. Is there a way to add the user control into an attribute value for our template style?
example :
<div class="<$tokenName/$>" />
this currently outputs an encoded user control, which is then not parsed by IIS.
Short answer: this is not possible.
Longer answer...
It's not IIS's job to parse the control... that happens when IIS hands off the request to the ASP.NET engine. ASP.NET does a single-pass parse through your ASPX before the Page lifecycle even starts... this is why controls you delcare in the ASPX are available during the Init event. Whenever your CMS expands "$tokenName", you are far past the point at which ASP.NET is interpreting your markup.
If you're having trouble with that, here's a thought experiment for you: What happens when $token expands into a user control that has some other $token2 control embedded in it? And that control contains some other $token3? How many times are you going to try and parse/expand/interpret your markup?
Not to name names, but for example, every pageview on all of Woot's forum pages (across four subdomains) returns a hidden __VIEWSTATE value that is about 54KB big.
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTIxMDUyNjY3MjAPZBYCZg9kFgJmD2QWAmYPZBYEAgEPZBYCAgEPFQERLi4vQmxvZy9GZWVkLmFzaHh
kAgMPFgIeBWNsYXNzBQljb21tdW5pdHkWCAIBDxYGHgRocmVmBRpodHRwOi8vc2hvcHBpbmcueWFob28uY29tLx4Ja
... about 55,000 characters later ...
XNweCNxOCI+SG93IGRvIEkgcmV0dXJuIGEgZGVmZWN0aXZlIHByb2R1Y3Q/PC9hPjwvbGk+DQo8L3VsPmRkJUr78qEqw4o
bS8B4e2RCjO08Nsg=" />
Would you guess that this is helping their servers by offloading something from being stored in the session, and possibly a DB backed session, or is this hurting their servers, and possibly all embedded sized clients, by being a big huge block of text? It does form about 1/3 of the total pageload.
In either case, do they probably need it?
if the viewstate is as big as you have mentioned I think the designers have not taken this into consideration before implementation.
The viewstate in ASP.NET pages can be even bigger than this. It can seriously increase the size of the page if the developer doesn't understand what it is and how to use it.
The new MVC application in ASP.NET doesn't use viewstate.
The viewstate is used to to track the state of the ASP.NET controls on the page and can also contain big chunks of data that is in those controls.
Just use an online viewstate decoder to see what they are storing. It looks like they are storing the dataset for the page.