...
Response Field to check: Body
Reference Name: VIEWSTATE Regular Expression: id="_VIEWSTATE" value="(\[\\w/-_\].+)" Wiki Markup
Template: $1$
Match No. : 1
Default Value: NOT FOUND
Response Field to check: Body
Reference Name: EVENTVALIDATION Regular Expression: id="_EVENTVALIDATION" value="(\[\\w/-_\].+)" Wiki Markup
Template: $1$
Match No. : 1
Default Value: NOT FOUND
Then in order to ensure these extracted values are passed in subsequent HTTP requests, for each request specify the following to be the Send Parameters for the Request:
Name: _VIEWSTATE
Value: ${VIEWSTATE}
Name: _EVENTVALIDATION
Value: ${EVENTVALIDATION}
...
Additional Note: (EmmanuelGuyot) What about the cases where VIEWSTATE is split into different part ? The field VIEWSTATEFIELDCOUNT is easy, but as _''_VIEWSTATExx fields number varies, is it possible to set a dynamic NAME in the Request ?
Additional Note: (SChauhanSonamChauhan) Concurring with FrankZimper - while testing an ASP.NET 2.0 site I had to add an additional leading underscore to the id fields in the regexes. , the fields it used had two leading underscores. I used regexs to extract and pass three fields between ASP.NET pages: +PREVIOUSPAGE, +VIEWSTATE, __EVENTVALIDATION
. These fields existed on all the ASP.NET pages, either cleanly stored in hidden HTML form fields, or in a couple of instances, strangely jammed in as invisible parts of the DOM using a weird, pipe-delimited syntax.
For extracting out hidden form fields, I used a simpler regular expression . Note the two underscores, and the '?' to denote non-greedy matchingthan the one in the article: id="
__+PREVIOUSPAGE"\s*value="(.*?)"
Also, some pages did not use a 'proper' hidden field and seemed to 'jam. For pages that had 'jammed-in' data into a pipe-delimited string. For these pagesdata, I had to use this type of regular expression instead: |
__+PREVIOUSPAGE|(.*?)|
Lastly, I used a these regexs for the PREVIOUSPAGE, VIEWSTATE, and EVENTVALIDATION fields (all prefixed with two underscores).
Note the '?' used to specify non-greedy regular-expression matching. I'm reluctant to replace the one in the main article, unless I know the reason for it.
I normally strip the automatically-generated 'Browser-derived headers' HTTP Header Manager element from my scripts. I found that doing so with the ASP.NET site resulted in page load errors. I can only ASP.NET assume uses the Header referrer for some strange reason. So, you may have to keep the 'Browser-derived headers' inThe funny thing was if I passed in unknown values.