This question already has answers here:
Cross-origin request in a content script is blocked by CORB despite the correct CORS headers
(3 answers)
Closed 6 months ago.
I've been trying for a while to make a HTTP REST API call from the frontend JS running on any page in my chrome extension to my backend server. I've read many stackoverflow answers but still haven't found anything good enough.
I have credentials: "include" and mode: "cors" set in my fetch call on the frontend. And I have Access-Control-Allow-Origin: * on the backend response set as well.
But the network request always fails due to a CORS error.
My chrome extension has code that runs on any webpage on any domain, so I'm effectively making the API call from an arbitrary domain to my http://localhost:8000 backend address, so e.g. I could make a call from "google.com" to my localhost address.
Also, I'm using chrome manifest v3. (I've also set "host_permissions": ["*://*/*", "http://localhost/*"], in the extension manifest file)
I believe I can move the API request to my backend work if I moved the call to a background service worker, but I'm really just curious as to whether or not it's even possible to do this cross origin request at all from a regular webpage. Any advice?
Sorry never mind, I just had to disable Block insecure private network requests. in chrome since that's what was blocking the local request
Related
I am making an ASP.NET application and would like to be able for my file upload to allow attachments to be dragged straight from Gmail. The problem is that I cannot load the data from the links dragged in because of cross-origin rules.
There are 2 problems:
First, cross-origin rules prevent me from making requests to the gmail attachment server.
Second, even if I were to make the request with cross-origin, the cookies would not be included.
I am using Chrome and only interested in doing this on my own computers.
One option is I could make a Chrome extension which allows cross-origin requests but only from my website.
Another option would be for my locally hosted server to communicate with Chrome to make the request itself.
Which of these would be the best option and how would I do it?
We recently started having issues with a web app used internally at our organization. Most users have been using Chrome to access the web app. The issue seems to correspond with the release of Chrome 90. The web app has been in place for a couple of years working with previous versions of Chrome without issue in this regard.
The web app uses an embedded iframe from a 3rd-party vendor. The vendor app does an HTTP GET to a URL within our web app to indicate success or failure. We then close the iframe and update our app accordingly. This has worked fine until recently. Now it seems that the HTTP GET from the vendor iframe is being 302 redirected to our login.
Example of 302 redirect
Prior to this and using MS Edge as the browser, the same HTTP GET gets a 200 response and our web app works as expected.
Example of HTTP 200 response
Since other browsers are continuing to work and there have been no significant changes to the web server, web app, or network access, we suspect something has changed with the latest version of Chrome and perhaps stricter security requirements. Why the 302 redirect? Does this have something with our SameSite cookie config? (Up to this point, we have done nothing specific with regards to SameSite).
We found that with the latest updates to Chrome, we had to set the ASP.Net Session cookie headers to include "SameSite=None; Secure".
This article provided the answer: https://web.dev/samesite-cookie-recipes/
I uploaded a static website in html, css and javascript in AWS s3. Ive already enabled CORS in the API and seem to be getting the correct request when invoking the URL. img
However, im still facing this Access-Control-Allow_Origin which is preventing the transition of pages in my website.
Ive been using a CORS extension in Chrome while developing the website, and it worked. Now that its in s3 I am having a bit of trouble configuring it.
Update: Here is the response that I get from creating the XMLHttp request. Can someone also explain to me why the chrome extension eliminates this error?
API Gateway OPTIONS Method Response:img1
API Gateway OPTIONS Integration Response: img2
My JavaScript Code img3
The users of our website run our Chrome plugin which, amongst other things, performs cross-origin requests via XMLHttpRequest as described on the Chrome extension development pages. This has been running just fine for a few years now. However, ever since our users upgraded to the latest version of Chrome (v38), these requests have failed. Our site runs on HTTPS and some of the URLs loaded via our content script are on HTTP. The message is:
[blocked] The page at 'https://www.ourpage.com/' was loaded over
HTTPS, but ran insecure content from 'http://www.externalpage.com':
this content should also be loaded over HTTPS.
The reported line where the error occurred is in the content script where I'm issuing the HTTP call:
xhr.send(null);
I have no control over the external page and I would rather not remove SSL from our own page. Question: Is this a bug or is there a workaround that I am not aware of?
(Note: The permissions in the manifest were always set to <all_urls> which had worked for a long time. Setting it to http://*/ and https://*/ did not help.)
If possible, use the https version of that external page.
If that is not possible, use the background page to handle the AJAX request (example).
I developed a chrome extension which communicates with IP phones.
The communication is done in a event page which is sending POST requests via the XMLHttpRequest object.
Because the hostname or IP address of the phone is configured in the options page I added optional_permissions to the manifest file and request them from the user after saving the options with chrome.permissions.request.
Cross-Origin XHR works now without any problems until I restart chrome...
After restarting chrome it seems like the requested permission is lost and I get the typical
is not allowed by Access-Control-Allow-Origin error.
When I click on the extensions permissions I can also see that my requested permission is no longer listed.
Because the chrome.permissions.request is only working for a user gesture I can't request it during the load of my extension or on the fly. If I request the permission again in my options page I don't get asked again whether I want to allow it or not put the permission is granted and everything works again as usual.
Is there a way to get this permission granted persistent after requesting it? I only want the extension to have access to the endpoints it needs.
Thank you very much.
For me the following reported issue answered my question:
Issue 158004: chrome.permissions.request support for user-supplied URL.
To make it clear: It is not possible to request a subset of the permissions defined in optional_permissions. If you define http://*/* then you need to request exactly this string! A subset like http://example.org/* wont work!
Here is a quote from a comment in the issue description which makes that clear:
"There's no wildcard handling, just plain string comparison between the URLPatterns"
The Issue has been fixed in Revision 182287
The only thing left is to cross your fingers that this fix gets included in a upcomming chrome release soon. We'll have to use the bloody Access your data on all websites permission in the meanwhile.