There are following column names under "User-defined cookies":
1. Name
2. Value
3. Domain
4. Path
5. Secure
What I should enter in all above mentioned fields and how it is useful?
HTTP Cookie Manager is smart enough to automatically take care about cookies. Being added and enabled it fetches cookies from Set-Cookie response header and adds them to the next request enabling client-side state management, cookie based authentication, etc. Moreover, it provides access to cookies via JMeter Variables assuming CookieManager.save.cookies=true property is set in user.properties file (lives under /bin folder of your JMeter installation).
In regards to fields like Name, Value, Domain, etc. - this way you can define your own custom cookies or override existing cookies if i.e. you need to hard-wire a request to this or that node behind the load balancer, simulate activity of certain user, whatever.
See Using the HTTP Cookie Manager guide for more details on this useful test element.
Related
We have moved our site domain from oldsite.od.ua to newsite.ua (not between subdomains and principal .tld).
Google Analytics continues to collect the same GA property and views, but all GA Client IDs changed. I know about cross-domain tracking, but in my case users don't visit the old domain to go to the new one.
Is there a way to transfer old IDs to the new domain?
We don't use the User ID because we don't have any authorization on our site.
That should be possible, while a little tricky.
You need to read the user _ga cookie that exists on the old site and set it for the same browser on the new site
This is only possible through a special redirect, here is a sample flow:
Accessing to newsite.ua would include in the source of every page of the news site a reference to a resource like an image on https://oldsite.od.ua/special/ga.png
That call is a pretext to allow reading the _ga cookie value on https://oldsite.od.ua/ for that browser through HTTP Request Headers
probably something like GA1.3.1218996493.1586263874
The request to ga.png would be handled by a PHP script for example, able to process HTTP Header values and it would do a 302 redirect to
https://newsite.ua/special/ga.png?ccvalue=GA1.3.1218996493.1586263874
This allows to pass the value of the former GA cookie to the new site context. You will be able to access the "_ga" cookie value in PHP with something like
$_COOKIE["_ga"]
The HTTP Response to the call to https://newsite.ua/special/ga.png?ccvalue=GA1.3.1218996493.1586263874 would have an HTTP header like this
Set-Cookie: _ga=GA1.2.1218996493.1586263874; Expires=<date in 13 months>
Thus passing through the value of the parameter as a cookie value. But only if the HTTP request to https://newsite.ua/ doesn't already holds a _ga in the Request Header (that would mean that the browser has already been migrated)
(You'll need to adjust the code to make sure it doesn't go into an infinite loop for example...)
Note that the ".3." at the beginning of the initial cookie value needs to be replaced by ".2." to match the _ga cookie generation rule on the new domain (it is based on the number of dots in the domain name, and allows GA to select the appropriate cookie between a domain and a subdomain) because in your case you move between different domain patterns
This applies to the analytics.js version
The GA debug extension will help you verify that it's taken into account
You should also consider handling user consent regarding tags and so in that migration..
I'm thinking about changing name of the default antiforgery cookie in ASP.NET Core.
The reason why I would like to change the cookie name is to anonymize the cookie, in my opinion there is no reason why end users should be able to determine the responsibility of this cookie.
Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieName
How do I change the name of the antiforgery cookie? I guess it should be done in the Startup.cs file in somehow?
What possible implications could occur by changing name the default antiforgery cookie?
How do I use the antiforgery cookie in ASP.NET Core?
Should different web applications (using same domain) share single antiforgery cookie, or should separate antiforgery cookies be created for each web application?
You can set a different name in your Startup.ConfigureServices as in:
services.AddAntiforgery(opts => opts.CookieName = "MyAntiforgeryCookie");
For .Net Core 2.0.0 or greater there will be changes:
Reference:
https://learn.microsoft.com/en-us/dotnet/api/Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions?view=aspnetcore-2.0
For that use following:
services.AddAntiforgery(opts => opts.Cookie.Name = "MyAntiforgeryCookie");
By default AddMvc() internally calls AddAntiforgery(), which means you get the default cookie, header and form names. If you need to/want to use different names, you can do so by manually calling AddAntiforgery as above.
There should be no implications for your application if you change the cookie name (unless you added code yourself that manually used that cookie). You might also want to change the header/form name, for example the offical Antiforgery repo has an example that uses Angular and changes the header as the standard angular XSRF token header.
In order to use it, add the [ValidateAntiForgeryToken] to controller actions other than GET requests.
You have to do nothing else for standard html forms as long as you use the asp form tag helpers, see this question.
If you use ajax requests, then you will need to include either a header or a field within your request that includes the generated token. You basically need to:
Get an IAntiforgery
Call var tokenSet = antiforgery.GetAndStoreTokens(httpContext);
Make it available to your js code so it knows about the value tokenSet.RequestToken to be included as either a field with name tokenSet.FormFieldName or a header with name tokenSet.HeaderName within each ajax request.
A few options for that like rendering the token into a JS object inside a script section in your js layout, adding a JS readable cookie as in the angular example, keep rendering hidden fields you include within the ajax request
There is a nice overview of the options in this answer
The aim is for POST/PUT/DELETE/PATCH requests to include 2 things:
the antiforgery cookie
the field/header with the token
So the antiforgery middleware can validate there was no XSRF.
Update about cookie name/domain
The sensible default is for each application to have its own cookie. You mostly get that with the default approach as no domain is specifically set on the cookie, so the cookie takes the domain from the request. That would mean different cookies for different applications unless the appliacations are hosted with the same domain.
Read more about how cookies work here
You might only want to share the cookie in special cases, for example if you have 2 applications where a form in app A posts to app B. In those cases make sure you use a domain/subdomain that matches both applications and both use the same cookiea name.
Read more about XSRF here
There was a weird issue yesterday about asp.net's outputcaching (webforms). We were using page-level caching (not partial caching) for a multi-lingual site (language is determined via querystring key) and for some purpose, caching stopped working for some languages. I kept track of GetVaryByCustomString method of Global.asax file but, it didnt worked. I will give more details in answer...
Perhaps you need to set the Shareable attribute on your cookies to true?
If a given HttpResponse contains one or more outbound cookies with
Shareable is set to false (the default value), output caching will be
suppressed for the response. This prevents cookies that contain
potentially sensitive information from being cached in the response
and sent to multiple clients. To allow a response containing cookies
to be cached, configure caching normally for the response, such as
using the OutputCache directive or MVC's [OutputCache] attribute, and
set all outbound cookies to have Shareable set to true.
https://msdn.microsoft.com/en-us/library/system.web.httpcookie.shareable(v=vs.110).aspx
Thanks to subversion, i kept track of recent commits. We made a mechanism allowing specific users to view some languages that have not been published yet, using cookies instead of session variables. This was the cause of problem. If a request comes to a language which is not the default language, this mechanism checks whether it should allow user to view page. And IMHO if you modify response's cookie collection, asp.net disables outputcache for that request. I tested it and it really disables cache if you add a cookie to response.
I want to share session between two different domains .
How can I do this using cookie . I want to share user id across two domains.
For example.
First website : www.example.com In ASP.NET
Second website : www.newwebsite.com IN PHP
When user comes in first website , after login it will redirect to second website.
I want to get user id from first website cookie. How can I achieve this using cookie. My both website are on different platform and hosted on different server.
Code :
// Create cookie on First website :
HttpCookie cookie = new HttpCookie("example ");
cookie.Values.add("Username", "user1");
//Want to retrieve on Second website
HttpCookie LoginCookie = Request.Cookies.Get("example ");
string x = LoginCookie["Username"].ToString();
Thanks in Advance
Cookies are tied to individual sites/servers via (weak) encryption. What you will need to do is tell IIS that they are the same via the Machine Key inside your config. Arguably you could do this inside of IIS but then there is no source control.
Milan Mathew provided a decent start for you here (http://www.codeproject.com/Tips/438319/Sharing-Authentication-Cookie-between-two-ASP-NET). Basically in both sites you apply the same encryption information.
<machineKey
decryptionKey="A225194E99BCCB0F6B92BC9D82F12C2907BD07CF069BC8B4"
validationKey="6FA5B7DB89076816248243B8FD7336CCA360DAF8" />
Keep in mind that depending on which version of IIS and .NET you are running will dictate how you set this up and which configs you apply this two. There have been recent modifications to how this is done.
Please provide more information for a more details on your setup for more specific assistance.
Any case, base your search criteria on this concept and you should be fine.
the HTTP protocol says, two different sites can share a cookie if and only if both sites are deployed under the same domain (or, sub-domain). Internally, your browser stores the cookies locally (either in disk or in memory) against the web site's URL. When you hit subsequent requests to any site, the browser reads those cookies which have matching domain or sub domain names comparing to the currently requested URL and sends those cookies with the request.
With JavaScript/HTML5's "LocalStorage" feature, if you're on myDomain.com:81 and you set a value in local storage, but then redirect to myDomain.com, the local storage will be different, and the value will be lost.
How can I store a simple value that exists across all domains in my browser?
If it makes a difference, this is for a Chrome extension.
I'm trying to do a file upload in Flex using it's FileReference class.
This works great in IE, but bombs in FireFox and Chrome. The issue is that Flex starts a new process for the POST but does not pass the authenticated user cookie with this request. The server gets the request, but attempts a redirect to the login page and... BOOM - 2038 Error!
I read here that I can pass the cookie information in the URL. I have not gotten this to work yet. Here are my questions:
Is this a standard feature in all servers to accept cookies in the URL (ours is Glassfish)?
Does the cookie portion of the URL start with the semi-colon (";")?
Can I add more than one cookie value and are those also delineated with semi-colons?
You can't pass cookies in the URL. You can pass session ID if server supports it. Java Servlet containers do support it (it's in Servlet spec) by using jsessionid path parameter. Just make sure ;jsessionid=... is right after the path, before query (it's called "path parameter" for a reason).
To your questions:
servlet containers do support jsessionid path parameters. In general, you can't pass any cookie this way.
Yes, path parameters start with semicolon.
No, those are not cookies. You can have multiple path parameters (separated by semicolon), but they won't be visible as cookies on the server side.