I have a site that is running in Node and using express for the server. I also have an API on a different server I need to hit. Everything works fine except in IE9. The issue is when ever i try to hit my API once i have the page loaded it breaks.
For example on the home page i have a search form where each step makes an API fetch and once I try to make my first fetch i get this error
"Unhanded promise rejectionError: Access Denied"
It seems like it has to do with a CORS issue since IE9 didnt have CORS and the era of the error message. Also when I make the fetched server side I have no issue, its just when the client tries to perform them.
Has anyone had an issue like this and if so how did you fix it?
Currently I am trying this but it hasnt worked yet:
First I changed my api host address to the current sites address with /api at the end.
apiHost: process.env.API_HOST || 'http://127.0.0.1:3000/api'
Then in my express server is run this:
app.use(modRewrite([`^/api/(.*)$ http://api.mysite.dev:8080/$1 [P]`]));
I was hoping to avoid making a fetch cross address with this but no luck as of yet.
Any help would be much appreciated
thanks!
To solve this problem I changed my host file for my machine to use mysite.dev for the 127.0.0.1 IP. Then went to mysite.dev rather than 127.0.0.1 when testing my site. Then did what I did above to get it to work
Related
As the title says, this only happens in Firefox. After some time the browser only sends OPTIONS requests with no responses, no status, no headers, nothing I can see in the debug console.
All of this works perfectly under Chrome, Safari and Edge.
I've already set up CORS middleware and headers within NodeJS, so that's likely not the issue. I'm completely lost right now.
After a lot of banging my head against a wall, I realised that an SQL query from the backend ORM wasn't finding one of the pieces of data I need on the frontend (it was null in the database), so Firefox instead of simply showing me that it's failing decided to just not show anything.
In short: if you have this problem just check for errors in your backend
I am having an issue with 'ERR_CERT_COMMON_NAME_INVALID' when making a request from a website.
First of all, am really a bit of a novice when it comes to setting up and using certs... so this is probably something stupid that I have ether done or not done!
I have a ssl certificate www.my-dummy-url.abc and api.my-dummy-url.abc (obviously my-dummy-url is for example only). Where api.my-dummy-url.abc is the certificate Subject Alternative Name and www.my-dummy-url.abc is the certificate Subject.
The Apache Web sever, is hosted at www.my-dummy-url.abc, whilst a reverse proxy points 'api.my-dummy-url.abc to a Raspberry Pi running a little node.js API endpoint (/weather).
I have set node.js up to use express: https.createServer(ssl_options, ..., where ssl_options is my cert.pem and key.pem. CORS is enabled (app.use(cors());) and 'Access-Control-Allow-Origin', '*' is present in the response.
The Website (apart from the API call) renders fine at https://www.my-dummy-url.abc (Chrome).
The API, (https://api.my-dummy-url.abc/weather) if requested within the address bar of a Chrome browser or through Postman receives the correct JSON response.
However, from my website as a jQuery $.get function I get the following error:
GET https://api.my-dummy-url.abc/weather net::ERR_CERT_COMMON_NAME_INVALID
Any ideas, helpers, pointer or solutions will be gratefully received...
As an addition, if I use Edge rather then Chrome, it works...!
Kind Regards,
Harold Clements
This issue was that Chrome was caching the certificate somehow. After shutting down and coming back to it the next day, it was working fine.
I use http://instagram.com/username/ this URL for image scraping from Instagram public profiles.
Everything works fine in localhost and works as I expect.
However, in the server(CentOS 7) scenario is different. It does not fetch the same response when I compared it with the localhost (I used "curl -v http://instagram.com/username/").
The only difference that I could understand in response headers is csrf_token is missing from the server and in localhost, with git bash, it gets attached immediately.
Any hints or answers are appreciated.
PS: I checked in different servers and it gives the same response so it cannot be that Instagram blocked the IP. ^_^
More importantly I use https://www.instagram.com/graphql/query/?query_hash=f92f56d47dc7a55b606908374b43a314&variables={"tag_name":"rose","first":25} this URL to scrape hashtag images and it works fine on both server and localhost.
If you can provide something like above is also fine ^_^
This is expected behaviour, Instagram isn't just going to let you scrape their whole website. They have access-control headers that prevent incorrect embedding and when you do cURL the page will be checking for certain headers, specifically an API key, which you haven't provided and so you are denied.
You need to use the Instagram API : https://www.instagram.com/developer
For several years we have successfully been uploading videos via the YouTube API using some custom JavaScript code. The code was based on some samples provided by Google (cors_upload.js). It's not something we use a lot, just every couple of weeks.
Things were working fine a couple weeks ago, but it has come to my attention that things recently stopped working. We login fine, we obtain the channel info fine. But when we start the upload (which happens via XHR POST), we are getting a CORS error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.googleapis.com/upload/youtube/v3/videos?part=snippet%2Cstatus&uploadType=resumable. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
But we haven't changed anything in our code or on our server and it appears as if we are doing all the things necessary as documented by Google to have their service respond with the required CORS headers.
According to the dev console, the XHR request actually generates 2 network requests. First I see an "OPTIONS":
Request URL:https://www.googleapis.com/upload/youtube/v3/videos?part=snippet%2Cstatus&uploadType=resumable
Request Method:OPTIONS
Remote Address:172.217.9.42:443
This actually DOES return the "access-control-allow-origin" header that I expect. However, this is immediately followed by the "POST" request:
Request URL:https://www.googleapis.com/upload/youtube/v3/videos?part=snippet%2Cstatus&uploadType=resumable
Request Method:POST
Remote Address:172.217.9.42:443
And according to the dev console, it does NOT have the "access-control-allow-origin" header set. So, I understand why my browser is rejecting things. It just seems like Google broke something.
I did successfully deploy a NodeJS "CORS Anywhere" server on a server we manage. So, I can use that to work around the issue. But that really isn't the correct solution to the problem. Since uploading videos programmatically isn't something we do a ton, this work around will probably be sufficient for us. I would love to understand what went wrong or how to fix. So, if someone is successfully uploading videos with the YouTube API and JavaScript, I would love to hear about it. Hopefully this will help educate others if/when they run into the issue.
The same problem just started to happen with my services.
It seems to be a bug on googleapis or maybe youtube.v3.apis had a policy change and started to block some clients.
Google has fixed the problem and our long-standing code is back to working again without any changes.
Here is the tracked issue:
https://issuetracker.google.com/issues/158718687
Same here. I have no Solution, just a workaround and I hope they fix it soon. You can disable the CORS safetycheck in chrome. Run chrome.exe with --disable-web-security and set the user-data Directory temporary to another location, with the following parameter and the folder you want --user-data-dir=c:/anyfolderName/`
For security reasons you should disable-web-security only if you have to and switch back if youre done.
I dont know why this get a downvote, because it helped me to get around. Now google fixed the issue, no need to use this workaround longer. But maybe it helps when another CORS issue arise...
I am trying to implement the quickstart application that has been posted here . I am doing everything as it has been instructed. On running the application i get a error of as shown in the screenshot
[01:19:19.661] GET https://accounts.google.com/o/oauth2/auth?client_id=590193668021-m0poda5f50214v9vjvlkqvsg08t0qses.apps.googleusercontent.com&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive&immediate=true&proxy=oauth2relay777233220&redirect_uri=postmessage&origin=http%3A%2F%2Flocalhost%3A8000&response_type=token&state=1371767407%7C0.2276743408&authuser=0 [HTTP/1.1 400 Bad Request 384ms]
I am unable to figure out what the problem is.
I am running the internet on a proxy setup in our college. ( Does it have any role in making it not work ?).
Please help. Thanks in advance.
UPDATE
Please run your application directly on a registered domain to test your code. It won't work on localhost straighaway.
For making it work on a localhost, one has to make a subdomain as instructed in the comments.
Thanks.