We have a legacy website which I'd like to supplement with a chrome extension as a temporary measure.
The site is set up with Spring Security and each request is authenticates with an access token.
I have tried creating an extension that makes a request to the endpoint visible from network requests with the correct data but the endpoint does not respond at all.
Running the same code directly on the website through DevTools gives me a proper response, so I'm thinking the error is due to CORS.
Is there a way to make a chrome extension run code directly on the page so there wouldn't be any CORS issues or should I approach this issue a different way?
Related
I have a project in ReactJs where I use web3.js to read from the smart contract and I an Ethereum client provided by Infura. Problem is, when I access my project in Google Chrome, everything works fine.
If I access my project via Microsoft Edge, I am getting the following error:
SEC7120: [CORS] The origin 'http://localhost:3000' did not find
'http://localhost:3000' in the Access-Control-Allow-Origin response
header for cross-origin resource at
'https://rinkeby.infura.io/v3/censored'.
I looked into other posts and I found this one which didn't solve my problem.
Other things I have noticed:
If I access the website from Internet Explorer, I can read data as normal. If I go to Google Chrome and not use MetaMask, I can read data as normal. If I activate MetaMask and I don't select the correct infura network (Ropsten) and I choose for example Main Network, it doesn't work as expected
UPDATE:
Seems that it's not an issue from my side and instead it comes from Infura. I enquired them to see if Microsoft Edge is a limitation of their service and if they are willing to do anything with it.
Ah the good old CORS problem. Since you don't have control of the server's CORS settings, you're better off creating a small server side application that will proxy these requests on behalf of your react application.
I'm trying to perform an ajax request to a third party api from my web site using javascript (On the client side) and I receive a No 'Access-Control-Allow-Origin' error. When trying to access this from node.js project everything is working fine.
More over, when opening Chrome with --disable-web-security everything is working fine as well.
Any information about this issue will be appreciated :-)
You cannot access a third-party API without using CORS. CORS adds special headers (e.g. Access-Control-Allow-Origin) to the HTTP response. This makes sure, that the API can control which front-end can make a request to it. This means, however, your API needs to recognize your front-end URL and accept requests from it.
You can (a) use CORS on the API side (changes are necessary on the API) or (b) use your server-side language to make the API request (e.g. PHP makes the request to the API and the front-end receives the response from the PHP back-end). Everything else is prohibited by the browser's security settings.
You can read more about CORS e.g. here.
I'm working on a website in my local development environment (Ubuntu 16.04) and testing the website on Chrome (58) via http://localhost.example/ - which connects to the local web server.
Running this Javascript:
$(document).ready(function() {
if (navigator.geolocation) {
navigator.geolocation.getCurrentPosition(showPosition);
}
});
Triggers this error:
[Deprecation] getCurrentPosition() and watchPosition() no longer work
on insecure origins. To use this feature, you should consider
switching your application to a secure origin, such as HTTPS. See
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins for more details.
Why is that? I understand that public facing websites need to be running HTTPS for the geolocation library/ functionality to work. We have a number of public websites running similar code across HTTPS.
However according to the depreciation documentation:
localhost is treated as a secure origin over HTTP, so if you're able
to run your server from localhost, you should be able to test the
feature on that server.
The above Javascript is running in-line in the HTML body loaded via http://localhost.example/test-page/ - so why am I getting the "insecure origins" error in Chrome?
Firefox (53) shows the in browser access location prompt, as expected.
Chrome considers localhost over http as secure. As you are using hostnme localhost.example over http, this is not considered as secure.
Note: Firefox will behave similarly as of Firefox 55
SSL over HTTP protocol ensures the private communication within Client and Server. The information might transmit through the private networks while transmission. Any third person (hacker) on the network can steal that information. To avoid that browser forces the user to use a secure connection.
On the local server, the information is not going beyond our private local network since there is not need of this kind of security. So we can expect a browser to allow geolocation without SSL on the local server. Ideally, the browser developer should skip this validation for localhost and 127.0.0.1 or similar origins.
There must be tricks available to avoid such issues i.e. you can install self-signed SSL certificate on the local server or you can edit the Chrome configuration file to allow domains to access the geolocation, webcam etc.
Helpful links,
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
https://ngrok.com/
webui-aria2 is a tool that allows controlling aria2 (powerful download tool) through rpc methods from a browser.
Using http://ziahamza.github.io/webui-aria2/, one can control aria2, provided the application is launched with the --enable-rpc option. aria2 basically starts an HTTP server listening on localhost:6800.
Great but I am surprised that the browser (both webkit and gecko) allows a page hosted on github.io to make requests to localhost. How come it does? Isn’t this a serious vulnerability?
Requests to localhost from github.io will be treated like any other cross origin request.
JavaScript embedded on the site can't read the data across origins unless either:
Explicit permission is given with CORS or
A hack such as JSONP is used
Presumably the server uses one of those techniques.
Regarding source maps, I came across a strange behavior in chromium (build 181620).
In my app I'm using minified jquery and after logging-in, I started seeing HTTP requests for "jquery.min.map" in server log file. Those requests were lacking cookie headers (all other requests were fine).
Those requests are not even exposed in net tab in Developer tools (which doesn't bug me that much).
The point is, js files in this app are only supposed to be available to logged-in clients, so in this setup, the source maps either won't work or I'd have to change the location of source map to a public directory.
My question is: is this a desired behavior (meaning - source map requests should not send cookies) or is it a bug in Chromium?
The String InspectorFrontendHost::loadResourceSynchronously(const String& url) implementation in InspectorFrontendHost.cpp, which is called for loading sourcemap resources, uses the DoNotAllowStoredCredentials flag, which I believe results in the behavior you are observing.
This method is potentially dangerous, so this flag is there for us (you) to be on the safe side and avoid leaking sensitive data.
As a side note, giving jquery.min.js out only to logged-in users (that is, not from a cookieless domain) is not a very good idea to deploy in the production environment. I;m not sure about your idea behind this, but if you definitely need to avoid giving the file to clients not visiting your site, you may resort to checking the Referer HTTP request header.
I encountered this problem and became curious as to why certain authentication cookies were not sent in requests for .js.map files to our application.
In my testing using Chrome 71.0.3578.98, if the SameSite cookie atttribute is set to either strict or lax for a cookie, Chrome will not send that cookie when requesting the .js.map file. When there is no sameSite restriction, the cookie will be sent.
I'm not aware of any specification of the intended behavior.