I have a page on domain A which loads a webworker script from domain B. The webworker is fetching some PNGs from doman A's server.
In Firefox, the request to get the PNGs contains the cookie for my site (domain A).
In Chrome, it does not include the cookie for my site, and so fails because the request must be coming from a logged in user (which requires the session cookie to be sent in the request).
Which browser is behaving correctly, and can I do anything to make Chrome send the cookie for the current domain from within a webworker?
UPDATE:
I pulled all the files from domain B and hosted them on my server at domain A, so the webworker file is now on the same domain as the site itself, but Chrome still does not send the session cookie with the requests from the web worker.
With regards to the first problem, it looks like the Firefox is incorrect, you shouldn't be able to instantiate a Worker on another domain to quote the spec:
"If the scheme component of worker URL is not "data", and the origin
of worker URL is not the same as the origin specified by the incumbent
settings object, then throw a SecurityError exception and abort these
steps."
With regards to Chrome the Workers run in a separate they work for me and without seeing more code it's hard to answer. But if you visit this demo and break before the postMessage to the worker set document.cookie='test=1' you will see that when the request goes out from the worker it is set.
Related
Assume I have an HTML page named ABC, host in https://fakehost.net/abc.html. And in its content, there is an image XYZ with src = '**https://fakehost.net/imgs/xyz.png**'
The host uses cookies so in the first time I visit that host (fakehost.net), the server send me cookies. And after that, every request to that host, the cookies will be attached.
When I visit abc.html, it internally send 2 requests, one for abc.html and another one for the image. The first one will attach cookies, I'm sure.
But how about the second one? The request to get the image? Is cookies attached?
You can find this yourself by visiting to the Network tab of the developer console. Check the request headers of the image requests and you will see that the cookie headers are sent.
And the answer is - yes. Cookies are sent in all the requests.
Here is more insight on this: https://stackoverflow.com/questions/1019370/are-cookies-sent-with-image-requests#:~:text=Yes%20cookies%20are%20sent%20on,be%20exploited%20to%20steal%20data.
I’m developing chrome push notification for my web site and doing the development in localhost (local machine) environment. Sending push notification is success with specific endpoint which I got when I subscribe the notification first time. I use same endpoint for all push messages.
Here sometime push notification got failed due to endpoint mismatch. When I see in chrome console (debugging mode) there was different endpoint.
Why chrome browser is changing endpoint? In this case how do we handle this scenario and update the new endpoint in the db?
sample endpoint:
https://android.googleapis.com/gcm/send/AWERdvfdfdsfdobRH4zlXGuyeuie3543uTBuP6air5dzZfltNa-FKF6K6S-9P5SdfbCbyvn9RdsfsdvU1XwSBwIrekjdK6_i4Cg-5rZAj8UvL1s-Bbr61yvvt_y2Hg9RdsyV
when i check next time, above endpoint got changed as like below
https://android.googleapis.com/gcm/send/reytryMkQwtY:YTUNMdsjjfhsdf349851VS6McDE7s_GITe_djsgfdkjghcdfdfgdftrkddfdsXiwX1vP_XclmDqrKPOAMJDfsYYXdhMX164694Q&ksdhfksdfhkjfhksdcndsk
Thank you.
The push notification endpoint is dependant on the service-worker. When a service-worker is unregistered and created again, the PushManager.getSubscription() method will indeed return null. You then need to call subscribe() again, which will return a new endpoint.
If you server tries to send a push notification to the first endpoint after the service-worker was unregistered, you will get a NotRegistered (for Chrome) or a Gone (for Firefox) error. So make sure to register the new endpoint as soon as the app loads or the device may become unreachable.
Note that this does not seem to affect service-worker updates.
Suppose I make a webpage that includes
<iframe src="http://google.com"/>
and a user browses through that iframe. Does Google see the request made from the server I'm hosting my site on, or from the user's router?
You do NOT load content of iframe source from your server. You just pass that code to the user browser then everything happens on client side. Therefore google will see client ip address and etc.
When one website is called through another domain whether iframe or not, browsers send current domain name to the next target (google.com in your case) with HTTP Referrer data. This is the only way of google.com to understand where the client request google from.
Details : What is the HTTP Referer if the link is clicked in an <iframe>?
I've added a G+ login button on my website, but I keep seeing this issue. In most cases this comes first time and if you try to connect after refreshing the page, it works.
Here's the error:
Uncaught SecurityError: Blocked a frame with origin .com" from accessing a frame with origin "https://accounts.google.com". The frame requesting access has a protocol of "http", the frame being accessed has a protocol of "https". Protocols must match.
I saw this post Google + SignIn Button Blocked Frame but the solution isn't relevant to me.
First, I want to emphasize that you really should be using https when handling user credentials. If you can, get an SSL certificate and serve your content over https. By using HTTPS, you can prevent MiTM attacks and user information leaks.
That aside, there are a number of potential sources triggering the warning:
If you are using the Sign-in button from a page serving HTTP instead of the more secure HTTPS, sometimes communication with the sign-in servers gets blocked. If sign-in sometimes works and sometimes doesn't, this may be the cause.
If your authorized JavaScript origin protocol (http / https) doesn't match, the Google authorization server will reject your client (http://yoursite.com when you meant https://yoursite.com)
If your authorized JavaScript origin does not match (e.g. you put .com in the authorized origin, when you meant yoursite.com) then the OAuth server will reject your frame.
Listing your authorized origins (obfuscated for security) from the Google Developer Console and the site might help to determine what's going on in your case.
A few things you can change to see if it helps:
Try changing your cookie policy to either 'single_host_origin' or to 'http://yoursite.com'.
Try cleaning the authorized origins in the developer console to only include your http:// domain.
Try accessing your site from an incognito tab, if this works, your browser cookies may be in a bad state for the site.
Try using Chrome network diagnostics to see if specific requests are failing.
Try replacing any includes that use an explicit protocol with includes referencing a relative protocol (e.g. replace <script src="https://foo.bar/include.js" /> with <script src="//foo.bar/include.js" />)
I am working on a google chrome extension and want access to all cookies that are included in the current request. I have the cleaned domain in the variable domain
So far the (relevant) code is
chrome.cookies.getAll({domain: domain}, showCookies)
Which works in getting the cookies that match at least the entire domain, but the same origion- policy means that if domain is gist.github.com then any cookies set on .github.com are also included in a request - but how do I get those "extra" cookies for any given domain?
My first idea was to cut of the part upto the first dot, but that does not seem correct.
"the same origion- policy means that if domain is gist.github.com then any cookies set on .github.com are also included in a request"
That's not really true. gist.github.com is a distinct origin from github.com and cookies aren't automatically included in the request. Something else is going on.
That said, if you
- set the domain to just "github.com" you'll get all github's cookies and gist.github's cookies and you can filter for yourself.