There doesn't seem to be much information around on forcing Cookie values in JMeter (2.8).
I'd like to be able to set a cookie at the start of a thread (AWS LoadBalancer ID), so that i can select a specific ID each time. The reason for this is that AWS gives the same ELB ID every time unless you change IP. I want to test more than one.
I have tried setting user-defined cookies in the HTTP Cookie Manager without success. (nothing is added)
I have also tried adding a COOKIE_Test to HTTP Header Manager without success. (adds to the header but doesn't treat as cookie)
Might not be possible?
Update: Adding the domain entry fixed it...
On inspecting the normal set-cookie, it omitted the domain, so i did the same...
I guess Cookie Manager ignores and user-defined cookies with null values.
Adding the domain entry fixed it
On inspecting the normal set-cookie, it omitted the domain, so i did the same...
Cookie Manager ignores any user-defined cookies with null values.
Did you try using the Cookie Manager User Interface?
http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Cookie_Manager
Related
I have mysite.com and mysite.nl.
I want to build single sign-on, someone signing in on .com should be signed in in .nl.
I do this by putting an image (1 pixel transparent PNG image) on the .nl domain which sends back a cookie in the response.
In my firefox dev tools, I see 'response cookie' and it's set. It looks like this:
I have made sure the domain is set to mysite.nl
But somehow, when I then navigate to mysite.nl I don't see the cookie set. Am I missing something? I tried disabling tracker blocking, but to no avail.
Google is doing it this way as well right? Ie., log in in Google and you're logged in in Youtube.
If the browser makes a request to xyz.mysite.com, it has to drop the domain cookie for mysite.nl. This is due to the browser security model. If you want to achieve Single Sign On between xyz.mysite.com and xyz.mysite.nl you need some technology to 'transfer' the session token between the two domains. Either you use a standards-backed technology like SAML or OIDC or you use a proprietary mechanism. If you carefully look at the HTTP response, you will see two Set-Cookie HTTP response headers, one has domain property set to mysite.com, one has set domain property to mysite.nl.
I jmeter.properties I set "CookieManager.check.cookies=false" but cross domain cookies still aren't working.
For example going this guide and using their demo site setting a cookie with a domain of "blazedemo.com" works, but if I change the domain to anything else it fails.
JMeter sends only cookies that match the domain of server in the request.
The property you've set impact the way JMeter read cookies not the way it writes them.
To check, emit a http request towards one host for which you created the cookie, you'll see it works.
As the owner of domain example.com with many content what security risks arising from providing subdomain to third party company. We don't want to share any of the content and the third company would have complete control over the application and machine hosting the subdomain site.
I'm concerned mainly about:
Shared cookies
We have cookies .example.com, so there will be sent also in the requests to subdomain. Is it possible for us to point A record to reverse proxy where we strip the cookies and send the request to third party provider without them?
Content loading from main domain
Is it possible to set document.domain to example.com and do XMLHttpRequest to the example.com?
Cross site scripting
I guess that it would be no problem because of the same origin policy. Subdomain is treated as separate domain?
Any other security issues?
We have cookies .example.com, so there will be sent also in the
requests to subdomain. Is it possible for us to point A record to
reverse proxy where we strip the cookies and send the request to third
party provider without them?
Great idea, you could do this yes, however you will also need to set the HttpOnly flag, otherwise they would be able to retrieve them with JavaScript.
Is it possible to set document.domain to example.com and do
XMLHttpRequest to the example.com?
No, subdomains for Ajax are treated as a different Origin. See this answer.
I guess that it would be no problem because of the same origin policy.
Subdomain is treated as separate domain?
JavaScript code could interact with each other subdomains - but only with the cooperation of your site. You would also need to also set document.domain = 'example.com'; If you do not do this, you are secure against this threat.
See here:
When using document.domain to allow a subdomain to access its parent
securely, you need to set document.domain to the same value in both
the parent domain and the subdomain. This is necessary even if doing
so is simply setting the parent domain back to its original value.
Failure to do this may result in permission errors.
Any other security issues?
You need to be aware of cookie poisoning. If evil.example.com sets a non host-only cookie at .example.com that your domain believes it has set itself, then the evil cookie may be used for your site.
For example, if you display the contents of the cookie as HTML, then this may introduce XSS. Also, if you're using the double submit cookies CSRF prevention method an evil domain may be able to set their own cookie value to achieve CSRF. See this answer.
I build up very simple test plan.
Login: POST, a session cookie is returned.
Get the state: GET, a user state is returned.
Create a resource: POST, JSON body is supplied for the resource.
So my 'Test Plan' looks like:
Test Plan
Thread Group
HTTP Request Defaults
HTTP Cookie Manager
Login (HTTP Request Sampler: POST)
Get State (HTTP Request Sampler: GET)
Create Resource (HTTP Request Sampler: POST)
The cookie generated by 'Login' is added to 'Get State' correctly.
But 'Create Resource' has NO cookie. I changed their order but it doesn't help.
I used the default options firstly and changed some options but it also doesn't help.
Is it a bug of JMeter? or just POST http request is not able to have cookie?
Please give me any advice.
[SOLVED]
I noticed that it is related to the path, not the method.
You'd like to look at the domain of the cookie as well as the path.
I mean, the path and the domain of a cookie could be defined in the server side through Set-Cookie header.
Another solution is to set CookieManager.check.cookies=false in jmeter.properties usually sitting besides the jmeter startup script in bin.
JMeter for some reasons thinks that you can't set the path=/something in a cookie if you are on http:/somesite/somethingelse. That is the path has to match the path your currently on.
I've never seen a browser enforce this limitation if it actually exists. I've seen and written several sites that use this technique to set a secure cookie and then forward someone say to /admin.
I wish this option was at least in the GUI so I didn't have to change the properties file. I think BlazeMeter is smart enough to turn off checking where flood.io is not. If it were up to me I'd just remove the code that checks this entirely. Why make the load tester any harder then it needs to be.
I had this turned on in my Spring Boot server which was causing the issue with CookieManager in jMeter:
server.servlet.session.cookie.secure=true
Removing this made the cookies flow ! Of course this is for localhost. For Production you may need this turned on.
I need to read a cookie created on https://sub1.domain.com from http://origin.domain.com using ColdFusion. I've seen a lot of info about how to create a cookie in a subdomain using CFCOOKIE, but I don't know how to access a cookie that already exists.
Will the HTTPS make this impossible anyway?
ADDENDUM:
The checked answer below correctly addresses the question as worded above. In my case, it did not work. I should have explained: The cookie on sub1.domain.com is created by a hosted third party product - not written in coldfusion and not under my control.
This is really quite easy. When you create the cookie, give it a domain attribute equal to your domain. The important part to remember is that it MUST have a leading dot.
<cfcookie name="mycookie" value="myvalue" domain=".mydomain.com" path="/" />
The leading dot tells the browser to send the cookie to any subdomain of mydomain.com which would include sub.mydomain.com and blah.mydomain.com.
You would then be able to access the cookie from any of the subdomains just as you would any other cookie:
<cfset thevalue = cookie.mycookie />
You should do this as a best practice to support older browsers.
Here is the statement from RFC2109: HTTP State Management Mechanisms that could affect older browsers
"To prevent possible security or privacy violations, a user agent
rejects a cookie (shall not store its information) if… The value for
the Domain attribute contains no embedded dots or does not start with
a dot."
I believe this is overridden by RFC 2965: HTTP State Management Mechanism which states
"Domain=value OPTIONAL. The value of the Domain attribute specifies
the domain for which the cookie is valid. If an explicitly specified
value does not start with a dot, the user agent supplies a leading
dot."
Which explains why it might be working for you in, presumably, a modern browser. I would still suggest you add it.