Is it possible to "pretend" that a request is coming from a certain IP address (e.g. setting a fake X-Forwarded-For header) when rendering a page using puppeteer?
Related
How could I block all requests using chrome DevTools?
I already know:
Block the network request that has been emitted: How to block a URL in Chrome's developer tools network monitor
But I want to block the request that doesn't happen.
Or is it possible to block all requests?
E.G.:
In the following request, https://stackoverflow.com/posts/... appears for the first time, but I don't want this request to be sent out (we are limited to the Fetch/XHR type), so I couldn't block this request before (there is a special case here is the above request is the same domain name as this request, so it can be resolved through the block domain name, but there was no request for the same domain name before in my scenario).
I tried to provide the Chrome browser with the IPv4 address of a website and it doesn't work. It returns something like : "The requested URL "[no URL]", is invalid". To be more specific I tried to contact www.nike.com ( ip address 2.17.140.185 ) . However when I try to contact facebook via ip 157.240.231.35 id does work. What's going on ?
You said it works if you try to visit http://157.240.231.35
Between your two tests you changed the IP address. You didn't change your web browser. This has nothing to do with Chrome.
When you make an HTTP request you include a Host header.
This allows a single HTTP server to host multiple websites on the same port.
Facebook's server is configured so if you request 157.240.231.35 then it redirects you.
Nike's web server isn't. It just throws an error message.
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 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.
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" />)