I have recently started using Request("key") instead of Request.QueryString("key") to access my querystring values. However I have read that:
Gets the specified object from the System.Web.HttpRequest.Cookies,
System.Web.HttpRequest.Form, System.Web.HttpRequest.QueryString,
System.Web.HttpRequest.ServerVariables
Therefore, if I have a querystring key and cookie key which are the same, which value is returned?
They're checked in the following order:
QueryString
Form
Cookies
ServerVariables
The search is short-circuited, so as soon as a matching key is found the value is returned.
So, to answer your question, a matching QueryString item takes precedence over Cookies.
Related
I did create a simple testcase in JMeter.
Open a form and all it's content (css, images etc) :
GET /
GET /css/site.css
GET /favicon.ico
GET /fonts/specific-fonts.woff
GET /images/banner.png
Wait a little...
Post the values
POST /
Receive the "Thank You" page.
- GET /thanks
In the response on the first GET is a hidden input field which contains a token. This token needs to be included in the POST as well.
Now I use the "Regular Expression Extractor" of JMeter to get the token from the response. So far, so good.
Then, after retreiving all the other contents I create the POST message, using the variable name in the RegExp-Extractor in the value field of the token parameter.
But... when executing the testcase it fills in the default value given and not the actual value of the token.
So... first step in debugging this issue was to add a dummy-HTTP-GET request directly after I get the token. In this GET request I also add the token parameter with the token variable as value, but now I can easily check the parameter by looking at the access-log on my webserver.
In this case... the URL looks promising. It contains the actual token value in the GET, but it still uses the default value in the POST.
Second step in debugging was to use the "Debug Sampler" and the "View Results Tree".
By moving the Debug Sampler between the different steps I found out the value of the token-variable is back to the default value after I receive the CSS.
So... now the big question is...
How can I make JMeter to remember my variable value until the end of my test-script ?
JMeter doesn't "forget" variables. However variables scope is limited to the current Thread Group. You can convert JMeter variable to JMeter Property which have "global" scope by i.e. using Beanshell Post Processor with the following code:
props.put("myVar", vars.get("myVar"));
Or by using __setProperty() function. See How to Use Variables in Different Thread Groups guide for details.
As you found it your problem comes from a misunderstanding of scoping rules in jmeter.
https://jmeter.apache.org/usermanual/test_plan.html#scoping_rules
In your case, just put the post processor of the request that will give you the response containing the child node.
Also I think you don't need to share this token with other threads so don't use properties as proposed in the alternate answer.
If I add a cookie to the response via Response.Cookies.Add(), the cookie also appears in Request.Cookies.
Is there any way to get to the original request cookies (ignoring newly added response cookies) without somehow caching Request.Cookies in advance?
There is another question that asks why this situation exists (a point that I'm clear on). I'm asking if there's any way around it.
Update
As a very rough filter, it seems you can look for cookies in Request.Cookies whose Expires is equal to default(DateTime). This is because when browsers serialize their cookies in the request, they don't include their expiration dates.
However, this wouldn't get rid of any cookies accidentally added to Response without an Expires.
Request.Headers["Cookie"] contains the raw header value sent by the browser. It's a semicolon-delimited list of key-value pairs. E.g.,:
key1=value1; key2=value2
Which can be parsed to a Dictionary<string, string> to figure out the request's original cookies (ignoring any that were added or modified by manipulating Request.Cookies or Response.Cookies).
(The values are URI-encoded to avoid any Bobby Tables situations for values containing equal signs or semicolons.)
Have found very interesting issue in asp.net with cookies:
when adding cookie with value like test&
using
HttpCookie cookie = new HttpCookie("test", "test&");
Response.Cookies.Add(cookie);
and then trying to retrieve value Request.Cookies["test"] trailing ampersand is lost. If it is not trailing it is not lost. In firebug or javascript data is correct so it is asp.net specific I think.
Of course mostly could say just use UrlEncode. But is it really necessary? Is there any list of disallowed charters for cookies (because I think it is smaller than for URLs)?
I have found similar topic but there is no & symbol in restricted list:
Allowed characters in cookies
The ampersand is not an allowed character in a cookie. It's necessary to encode the cookie data with the UrlEncode method.
System.Web.HttpUtility.UrlEncode(cookie);
See also these SO questions/answers:
Broken string in cookie after ampersand (javascript)
How do you use an Ampersand in an HTTPCookie in VB.NET?
url:http://localhost:51806/fair/PersonPage/personalPages.aspx?idCompany=1338006699#Site/AboutAs
request["idCompany"];
this code return null
how can get value idCompany
EDIT
Request.UrlReferrer.Query
this return ?idCompany=1338006699
this Request.UrlReferrer.Query.Split('=')[1] return 1338006699
but i think this way does not good way
#Site/AboutAs is a tab aboutAs in full tab component
Try this instead:
string id = Page.PreviousPage.Request.QueryString["idComapny"];
If no luck then your method of splitting is the best you can achieve, as you're trying to read the query string of the referrer page.
One work around though is to store the value in that previous page.
To do this, store the value of Request["idComapny"] in the previous page, where it should be available, in Session then you can read the Session value in any other page.
I want find a platform/language agnostic solution to ensuring the origin of a FORM POST is from an expected source. I.e. Page1.aspx posting to Page2.php within the same web site.
Specifically what I am attempting to do here is to prevent request forgery.
Use a hidden field in your form, which contains a token your app generated. Store the token in the user session. When the form is submitted, your app will check that the value of the hidden field is identical to the value stored in the user session.
If it is identical, then you know the submitted form comes from where it is expected to come.
Old Thread, but might still be useful.
If you do not have session info set (best option) then you can include a hidden field with an encrypted timestamp then compare it (after de-crypt) to the current time on the process end to make sure it is relatively close and thus as recent as you deem necessary.
You could include into the form a hidden field which would be the SHA1Hash("some-secret" + Remote_IP + PerSessionSecret).
The PerSessionSecret is something you autogenerate in the beginning of the session. "some-secret" is a global secret value - which will help a little bit in case the randomly generated PerSessionSecret turns out not to be very random enough.
Then do the same calculation upon the form submission and you know it's most probably submitted from the same client that it was sent to. (Of course, if you have multiple clients behind the single address, like a proxy or a NAT, you can not distinguish between them reliably).