While I was trying my project on localhost it was working fine, using https://cors-anywhere.herokuapp.com/ since I got the CORS problem. But once I deployed the site on Netlify, it gave me the error 426 (Upgrade Required), with or without using https://cors-anywhere.herokuapp.com/.
These are the messages that appear on my console:
>Failed to load resource: the server responded with a status of 426 (Upgrade Required)
>Error: Request failed with status code 426
at createError.js:16
at settle.js:17
at XMLHttpRequest.<anonymous> (xhr.js:61)
I have been searching and some people seem to have similar problem to this. I have seen solutions like having my own server to pass the requests, but I don't know how to do it and, correct me if I am wrong, wouldn't that be the same as using https://cors-anywhere.herokuapp.com/?
Newsapi changed their pricing model.
You can't make requests from the browser anymore, you'll have to use a backend. I had the same problem and the easiest way around it was implementing a Node (Express) server.
I guess the free plan simply is not longer available in production.
"Requests from the browser are not allowed on the Developer plan, except from localhost."
Here's the updated plan page..
https://newsapi.org/pricing
Actually newsapi.org api in developer plan is no more working in production.
because in developer plan CORS is only enabled for localhost.
Developer Plan $0
CORS enabled for localhost.
https://newsapi.org/pricing
but if you want to fetch news in production then there is a alternative for this which have 1000 request per month free works in production also .
https://newsapi.in/
Newsapi.in this website provide api that have cors enabled for all origins.
Enjoy...
As others have mentioned, Newsapi no longer allows you to make requests from the browser.
newscatcher has a no-card free tier that allows for 10,000 requests. On top of that, depending on your use case you can even mail them to increase the limits for a short span of time, or to add extra data points.
Related
We are using AWS Amplify for our NextJS web app and keep receiving error when ever I try to load the application once deployed to Amplify. Locally there is no issue.
I am using Amplify's default Auth configuration, with basic email and password auth. It looks like it could be related to the Amplify cookie being set in the header but I cannot find any documentation within AWS to prevent this or reduce the amount of information passed with the header. Any help would be appreciated.
I have faced the same issue and was able to solve it. Here's how -
Identify the CloudFront Distribution ID for your app. You can find it in the Deploy logs of your app build console.
Search & open that particular CF Distribution and go to the Behaviours tab.
Select the Default behaviour (5th one in my case) and hit Edit.
Scroll down to the Cache key and origin requests section.
Here you will find settings to control what's included in the headers of the request that goes to the server. In my case, I didn't need any Cookies so I chose None, and it solved the issue for me.
In your case, you can do the same or pick what all info needs to be in the headers.
Check to see if there are any unnecessary cookies for that domain.
I was getting this error (on a site I don't own). I took a look at the request headers and found a very large number of cookies (several dozen) for the site's domain. I cleaned up the cookies which seemed non-critical and the error went away.
As the error implies, the size of the entire request header section is above 8192 bytes. Request headers include the accept headers, the user agent, the cookies, etc. and all combined can get rather large. Large headers look malicious to some WAFs. I once had a single user having trouble with our site. Turns out they were a polyglot and had configured their browser to accept several dozen languages causing their accept-language header to be suspiciously long, and the WAF refused to proxy the request.
I faced the same issue using Nextjs, amplify and an external Auth provider.
The problem is that AWS S3 service has a request header maximum allowed size of 8192 bytes, so when ever you try to access the static generated pages of Nextjs it returns that error. This has already been asked here
In my case, I was using an external Auth provider and I was able to solve the issue configuring the cookies only for the '/api/' path. That way the Auth cookies are sent only to the Nextjs api endpoints, so your request header is lighter whenever you try to get the static pages.
I'm in the process of deploying my React site to AWS via Amplify, and the first step on the site is authenticating with Spotify. Here in their auth guide, they call the type of auth I am performing "Authorization Code Flow" where the first step is the site requesting a scoped auth and receiving a code via a http redirect.
This all works fine and dandy when I am running the app locally - the network logs and associated looks like this (apologies, I'm not sure how to best reproduce for you this devtools output):
localhost network logs
localhost initiator chain
But when I attempt this on my live site soundfound.io I instead receive in additional redirect which makes it impossible for me to retrieve the code (I believe at least - I could not figure out a workaround where I just capture the code from the 2nd 302 here but if you do, please enlighten me b/c I'm at the end of my rope here).
live network logs
localhost initiator chain
and here - my boilerplate AWS Amplify domain config: https://ibb.co/SV1N809
I've been reading up but this is just not clicking with me - WHO or WHAT is causing this additional redirect? It's certainly not the React application itself, that doesn't make any sense. Spotify knows about both redirect urls (localhost:3000/redirect and soundfound.io/redirect) so I don't understand how that could behave differently. The only place I can think to look is within the domain registration and control part of AWS Amplify - but I don't see (or don't understand) anything that would cause this sort of issue?
I'm just so lost as to where to begin trying to troubleshoot this, any and all help would be appreciated. Thanks
The AWS Amplify automatically creates a rule in the console App settings under "Rewrites and redirects" that redirects all requests to my base domain "soundfound.io" to "www.soundfound.io". Erasing this rule solved the issue.
Let's say I use the website: redacted.com
Website works fine when I am using it normally.
When I start using BURP SUITE PROXY to intercept requests, I start to have this error:
[2021-04-14T02:45:46.724Z] #firebase/firestore: Firestore (7.24.0): Could not reach Cloud Firestore backend. Backend didn't respond within 10 seconds.
This typically indicates that your device does not have a healthy Internet connection at the moment. The client will operate in offline mode until it is able to successfully connect to the backend.
Error: Uncaught (in promise): FirebaseError: [code=unavailable]: Failed to get document because the client is offline.
Please provide me the solution to this.
The answers do not work anymore due to the Firebase updates - i will give you a short instruction on how to find your custom match-replace rule:
make sure to activate "Intercept Server Responses" in the proxy options tab.
go "intercept" tab
set your burp proxy to "intercept is on"
type "this.forceLongPolling" in the search bar on the bottom
forward the requests until you find a match
there should be a pretty big response file containing something like this:
constructor(t,o,u,p,D,Q,Te,it){
this.databaseId=t,this.appId=o,this.persistenceKey=u,this.host=p,this.ssl=D,this.forceLongPolling=Q,this.autoDetectLongPolling=Te,this.useFetchStreams=it
}
in my case it contains the string "this.forceLongPolling=Q"
now create a match replace rule for this very special string to replace "this.forceLongPolling=Q" with "this.forceLongPolling=true" and make sure to choose "response body" as type:
Screenshot Rule
Using the idea of this troubleshoot (https://github.com/firebase/firebase-js-sdk/issues/1190#), i made the following Match and Replace in my Burp Suite and it worked!
this.forceLongPolling=void 0!==t.experimentalForceLongPolling&&t.experimentalForceLongPolling
to
this.forceLongPolling=true
And someone said before
This can change depending on the version of firebase-js-sdk so it's best to look around for experimentalForceLongPolling within your JS files and make sure it gets enabled.
Workaround for this issue (source).
For Burp, the following match and replace worked for me:
this.experimentalForceLongPolling=!!t.experimentalForceLongPolling
to
this.experimentalForceLongPolling=true
This can change depending on the version of firebase-js-sdk so it's best to look around for experimentalForceLongPolling within your JS files and make sure it gets enabled.
Faced the same issue. What worked for me is adding “firestore.googleapis.com” to the “No proxy for” option in Firefox’s proxy configuration.
Firefox Proxy Configuration
We have an existing site that is built and deployed in Adobe CQ5.5.
Now we are planning to migrate it to AEM 6. We have successfully installed the instance and deployed the site.
But when we try making any changes like adding a new component it does not allow the operation. It says something "Your request could not be completed because you have signed out"
See: http://docs.adobe.com/docs/en/dispatcher/security-checklist.html#par_title
AEM 6.1 has cross-site request forgery security features that requires you to do a bit of work to allow the /bin/wcmcommand request to authenticate from the dispatcher.
To see what I mean, open up your dev tools and go to the Network tab. When you try the action, you should see a wcmcommand request:
I bet you are getting a status code of 401 or 403.
Follow the instructions I started this post with to fix this.
Good luck!
#bfosterscripps provided this link which was helpful.
https://docs.adobe.com/docs/en/dispatcher/security-checklist.html#par_title
Just to follow-up. I faced this issue, and for us it was caused by a misconfiguration of the distpatcher. Adding a rule for "CSRF-Token" made the difference. You may also need to check that /libs/granite/csrf/token.json is not blocked.
/authorfarm {
# client headers which should be passed through to the render instances
# (feature supported since dispatcher build 2.6.3.5222)
/clientheaders {
....
"CSRF-Token"
}
I use Uber's API to create a WordPress plugin so people can order taxis to your physical location.
I'm looking at integrating the Price Estimates using the endpoint here - https://developer.uber.com/v1/endpoints/#price-estimates - I've a solution but having a bit of problem implementing it.
I'm getting an error on testing which in Google Chrome Developer Tools which states "Request header field Access-Control-Allow-Origin is not allowed by Access-Control-Allow-Headers."
I suspect it's due to the fact that the testing server is insecure, as the app Origin ID and Redirect ID begins with https:// (as I'm unable to add http://).
Will I be able to access the price estimates over http at all? I'm using the server_token way of authentication as feel it's probably the best way to do it.
Any help would be gratefully received :)
The Uber API only, and will only ever, support HTTPS.