Is there any way to pass cookie to IWebBrowser's Navigate method.
As far as I can see neither passing Cookie header in headers nor InternetSetCookie/InternetSetCookieEx works with IE11.
The only working method I found is to set cookie via put_cookie of IHTMLDocument2, but for that you have to load page first.
Is there any way to pass cookie to first call of Navigate?
You could try IESetProtectedModeCookie if you are interacting with low-integrity browser controls. This still has limitations as noted in this cookie FAQ:
IE10+ on Windows 8+ introduced Enhanced Protected Mode which uses
AppContainers (rather than Integrity Levels) for isolation. EPM does
not offer an API for interacting with cookies;
IESetProtectedModeCookie will not set the cookie inside an
AppContainer.
Creating AppContainers is not documented so I assume your process is not running in a AppContainer?
This newsgroup thread confirms that you cannot set a cookie in the headers:
In case anybody is interested, I went through Microsoft support to
find out more about this. Their answer: what I want to do is not
supported. The 'headers' argument to Navigate/Navigate2 CANNOT be
used to set cookies.
I'm guessing that refreshing the page after put_cookie is unacceptable?
Related
I've just noticed my console is littered with this warning, appearing for every single linked resource. This includes all referenced CSS files, javascript files, SVG images, and even URLs from ajax calls (which respond in JSON). But not images.
The warning, for example in case of a style.css file, will say:
Cookie “PHPSESSID” will be soon treated as cross-site cookie against “http://localhost/style.css” because the scheme does not match.
But, the scheme doesn't match what? The document? Because that it does.
The URL of my site is http://localhost/.
The site and its resources are all on http (no https on localhost)
The domain name is definitely not different because everything is referenced relative to the domain name (meaning the filepaths start with a slash href="/style.css")
The Network inspector just reports a green 200 OK response, showing everything as normal.
It's only Mozilla Firefox that is complaining about this. Chromium seems to not be concerned by anything. I don't have any browser add-ons. The warnings seem to originate from the browser, and each warning links to view the corresponding file source in Debugger.
Why is this appearing?
that was exactly same happening with me. the issue was that, firefox keeps me showing even Cookies of different websites hosted on same URL : "localhost:Port number" stored inside browser memory.
In my case, i have two projects configured to run at http://localhost:62601, when i run first project, it saves that cookie in browser memory. when i run second project having same URL, Cookie is available inside that projects console also.
what you can do, is delete the all of the cookies from browser.
#Paramjot Singh's answer is correct and got me most of the way to where I needed to be. I also wasted a lot of time staring at those warnings.
But to clarify a little, you don't have to delete ALL of your cookies to resolve this. In Firefox, you can delete individual site cookies, which will keep your settings on other sites.
To do so, click the hamburger menu in the top right, then, Options->Privacy & Security or Settings->Privacy & Security
From here, scroll down about half-way and find Cookies and Site Data. Don't click Clear Data. Instead, click Manage Data. Then, search for the site you are having the notices on, highlight it, and Remove Selected
Simple, I know, but I made the mistake of clearing everything the first time - maybe this will prevent someone from doing same.
The warning is given because, according to MDN web docs:
Standards related to the Cookie SameSite attribute recently changed such that:
The cookie-sending behaviour if SameSite is not specified is SameSite=Lax. Previously the default was that cookies were sent for all requests.
Cookies with SameSite=None must now also specify the Secure attribute (they require a secure context/HTTPS).
Which indicates that a secure context/HTTPS is required in order to allow cross site cookies by setting SameSite=None Secure for the cookie.
According to Mozilla, you should explicitly communicate the intended SameSite policy for your cookie (rather than relying on browsers to apply SameSite=Lax automatically), otherwise you might get a warning like this:
Cookie “myCookie” has “SameSite” policy set to “Lax” because it is missing a “SameSite” attribute, and “SameSite=Lax” is the default value for this attribute.
The suggestion to simply delete localhost cookies is not actually solving the problem. The solution is to properly set the SameSite attribute of cookies being set by the server and use HTTPS if needed.
Firefox is not the only browser making these changes. Apparently the version of Chrome I am using (84.0.4147.125) has already implemented the changes as I got this message in the console:
The previously mentioned MDN article and this article by Mike Conca have great information about changes to SameSite cookie behavior.
Guess you are using WAMP or LAMP etc. The first thing you need to do is enable ssl on WAMP as you will find many references saying you need to adjust the cookie settings to SameSite=None; Secure That entails your local connection being secure. There are instructions on this link https://articlebin.michaelmilette.com/how-to-add-ssl-https-to-wampserver/ as well as some YouTube vids.
The important thing to note is that when creating the SSL certificate you should use sha256 encoding as sha1 is now deprecated and will throw another warning.
There is a good explanation of SameSite cookies on https://web.dev/samesite-cookies-explained/
I was struggling with the same issue and solved it by making sure the Apache 2.4 headers module was enabled and than added one line of code
Header always edit Set-Cookie ^(.")$ $1;HttpOnly;Secure
I wasted lots of time staring at the same sets of warnings in the Inspector until it dawned on me that the cookies were persisting and needed purging.
Apparently Chrome was going to introduce the new rules by now but Covid-19 meant a lot of websites might have been broken while people worked from home. The major browsers are working together on the SameSite attribute this so it will be in force soon.
I'm truing to verify that 301 redirects are configured correctly in my webapp. When I send a request I want to receive 301 response with new expected location header.
It appeared that instead of 301 I receive 200 because of the Postman setting 'Automatically follow redirects' which is enabled OOTB. Disabling the setting fixes my tests.
I'm just wondering how to store this configuration somewhere in the collection? I do not want any other dev (or CI?) to know that there is some setting in the Postman tool that needs to be changed. What if I work on two collections simultaneously where one requires the setting to be disabled and the other one is not?
If you're using Newman, in your CI system, there is a setting for this that you can pass as an argument from the command line. --ignore-redirects.
https://github.com/postmanlabs/newman#newman-options
There are changes coming in to bring this down to the request level in the UI to make it more visible. Currently, there is not a programmatic way to do this in the Collection.
You could include this requirement in the Collection or Request Description, so others would know this needed to be disabled. Likewise, if this was a feature that you enabled without telling these external folks, how would they know that?
If it's something that you would like to see included in the app, you could create a feature request for it on the GH issue tracker repo, it's the only sure-fire way to tell the Postman Team, that this would be a cool feature to include.
https://github.com/postmanlabs/postman-app-support/issues
I try do develop a web application with ExtJs 4.0.
On startup the application sends a request to a server. This server sends a response. The responses' header contains Set-Cookie:"connect.sid=foobar"
When I look into the preferences of my browser, I can see that the cookie was created correctly.
My problem is that somehow I cannot access this cookie in my ExtJs application and I don't know why.
I tried to retrieve it with the following methods:
document.cookie.split(";")[0]
Ext.state.Manager.get("connect.sid"); => of course I initialized the state manager with a cookie provider
Ext.util.Cookies.get("connect.sid");
No matter which method I use, I get always undefined as return value
I hope somebody can help me, because I really don't understand why it does not work.
Thanks in advance.
Finally I found the problem.
The httpOnly flag was set in the response header. Therefore the cookie was not accessible for java script.
I'm creating my own (multi threaded) ISAPI based website in C++ and I'm trying to implement correct session management.
The problem is that when a new session should be created, the session is created twice when using subsequent requests in the generated web page.
Here's how it works:
- Client requests http://localhost and sends either no cookie or a cookie with an old session ID in it.
- Server looks at the session cookie and feels that it needs to create a new one because it no longer exists: it prepares a header with a cookie in it with a new session ID and sends the complete header to the client (I tracked this with http live headers plugin in firefox and it is correct). It also prepares some data like the page and and stuff like that (not yet body data, as it is still processing data from the database and stuff like that) and sends what it has back to the client.
- Client should have this new session cookie now, and sees the stylesheet link and immediately sends the stylesheet request http://localhost/css to my server. But... he still does this with the old session ID for some reason, not with the newly received one!
- Server sees this request (with again an no longer existing session id), generates another new session and sends the new session id with a cookie along with the stylesheet data.
So the client has received two session id's now and will from now on keep using the second one as the first one is overwritten, but nevertheless the first page has used the wrong session (or actually, the second page has).
You could say that this is not a problem, but when I start using personalized stylesheets, I will have the wrong stylesheet on the first page and as the page will use AJAX to refresh the content (if available), it is possible that the stylesheet is never reloaded unless the client refreshes.
So, is this a problem that is always there when doing this kind of thing? Will the browser always send an old cookie although it has already received a new one but is still processing the page? Is this a problem that, for example PHP, also has?
Note: before all the discussions start about "use php instead" or something: I am rewriting a website that I had first written in PHP, it became popular, had thousands of (real) visitors every hour and started killing my server (the website doesn't make that kind of money that I can throw lots of servers at it). By writing it in C++, requests take 2ms instead of 200ms in PHP... I can optimize everything. By taking my time to develop this ISAPI correctly, it is safely multi-threaded and can be multi-processed, multi-servered. And most of all, I like the challenge.
Added note: It seems that the problem is only there when an old session exists in the cookies, because when I completely clear all cookies from my browser, and a new one is created and sent back to the client, the subsequent stylesheet request immediately uses the given session id. This seems to be some kind of proof that I'm doing something wrong when an old session id is sent... Should an existing cookie be deleted first? How?
Added note: The cookie is written with an expire-date one year ahead.
I have found out what the problem was, I was in the assumption that setting a cookie without specifying a path would result in making the session work on all paths on that domain.
By using http://foo.bar/home as main page and http://foo.bar/home/css as stylesheet, internally translating that url to ?s1=home and ?s1=home&css=y, I was actually using two different paths according to the browser which did not pass the cookie to the css-request.
For some reason, they actually got together afterwards, I don't fully understand why.
Isn't this silly? Will people not often have a http://foo.bar/index.php and a http://foo.bar/css/style.css.php , just because they use subdirectories to keep their structure clean?
If anyone knows of a way to fix it, to make subpaths also work with the same cookies, let me know, but as I understand it from the definition of cookies, they are stuck within a specific path (although, it seems that if you specifically add a path other than /, it will work on subdirectories as well?)
Is there a way to get a list of all the cookies set by a website using WatiN?
The IE Browser class in WatiN provides a GetCookie method that allows you to retrieve a specific cookie, but I would like to iterate over all the cookies that have been set.
There are two methods that should allow you to get the cookies:
CookieCollection cookies = _browser.GetCookiesForUrl(new Uri(url));
and
CookieContainer cookies = _browser.GetCookieContainerForUrl(new Uri(url));
But both of these are empty. Also calling the GetCookie method for a specific cookie returns null.
Any suggestions of how to get this to work?
Recently I had to deal with this situation. At first I thought the cookies I was looking for were HttpOnly, but I took a look using WireShark and there was no HttpOnly flag.
Not sure why GetCookieContainerForUrl fails in this case, but a client side script call revealed the cookies were still there:
ie.Eval("document.cookie");
You might want to try that statement before resorting to packet sniffing every time.
Well, I suppose those methods should work as expected, but maybe you are trying to get HttpOnly cookies? Many sites/web frameworks sets this flag for important cookies, especially when it comes to "session id" cookies. You can't read them in WatiN and it's really hard to read them at all. I was looking for solution once and only one I got was article: Retrieve HttpOnly Session Cookie in WebBrowser
If you want to know if the site you are trying to get cookies is setting HttpOnly flag on the cookie, use Fiddler2 and look in response headers.