I'm making a React app and trying to use Auth0 to authenticate. After trying to log in, it returns this:
XMLHttpRequest cannot load https://my-domain.auth0.com/usernamepassword/login. Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'. Origin 'http://localhost:3000' is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.
I thought it would be related to this: CORS problems with Auth0 and React but I have both http://localhost:3000, http://localhost:3000/login in the 'Allowed Origins (CORS)' spot in Auth0's settings (and yes I'm using the correct client ID as well).
I tried putting http://localhost:3000/, http://localhost:3000/login in the 'Allowed Callback URL's (don't know exactly what that does) but that didn't work either.
When I use the social connection (Google) it allowed me to login after putting http://localhost:3000/login in the Allowed Callback URL's.
But it still won't work for just a new user logging in.
Any help?
If it makes a difference:
Auth0 Logs show for the social login but there are no logs at all for when I connect otherwise
I think related to this is that I also get this every time I load the page:
There was an error fetching the SSO data. This could simply mean that there was a problem with the network. But, if a "Origin" error has been logged before this warning, please add "http://localhost:3000" to the "Allowed Origins (CORS)" list in the Auth0 dashboard: ...(link to my dash)
I get a 404 from the gravatar website
Also I get these errors (may not be related):
Refused to set unsafe header "accept-encoding"
Refused to set unsafe header "user-agent"
Something was wrong with the client in Auth0. I don't know what it was but I built an Angular4 app and connected to the same client in Auth0 and got the same errors. I then tried deleting the client in Auth0 and making a new one and now it works. I have no idea what was causing the error, but creating a new client and connecting to that one fixed the issue.
Related
I'm running a React frontend and a Flask backend. I don't understand anything.
Let's talk CORS. CORS is Cross-Origin Resource Sharing. So why does Chrome complain about CORS when I'm running both my frontend and my backend on the same host?
So I enable CORS on my Flask backend, and continue on my merry way.
I'm not stupid so I'm like, how do I keep my user's data if they accidentally refresh or close the page? Well luckily Flask has cookies built in with session. So I go ahead and store the important things in session, and in componentDidMount, I try to fetch some important things. But after refreshing, Flask forgets the session, and my fetch returns no useful data.
I tried to look this up for a while, and I see interesting looking things, like the credentials parameter to fetch. If I write in {credentials: "include"}, according to the docs:
Always send user credentials (cookies, basic http auth, etc..), even for cross-origin calls.
So ostensibly, this should solve my problem and somewhat resolve my confusion, but, of course, no such luck:
Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'. Origin 'http://localhost:3000' is therefore not allowed access.
Please, help me understand what's happening, and how I can fix it.
I'll keep doing my research.
In short:
Your server should say it support credentials. support_credentials=True in Flask which results in Access-Control-Allow-Credentials: true Header.
Your frontend should include credentials in request: {credentials: "include"}
Your server should return not wildcarded Access-Control-Allow-Origin ie http://foo.example instead of *.
It's best to use browser's dev tools to troubleshoot it.
Have a look here for bigger explanation: https://stackoverflow.com/a/7189502/803174
So I found a solution, but I'm willing to accept an answer that clearly explains what's going on.
My solution was adding supports_credentials=True into my Flask app, such that the line of code looks like:
CORS(app, supports_credentials=True)
I can then add credentials: 'include' into my fetch request, and cookies seem to be successfully stored.
I'm able to build my own oauth2 server following this example
I then created my own client side app with frontend being react. I specifically used facebook's create-react-app to get a quick start point.
I also found that in order to run the frontend in dev mode while connecting to backend api, I need to have a proxy added in the package.json file.
Now I have everything at hand:
The oauth2 server running on "localhost:8080"
The client app api running on "localhost:9090"
The frontend running in dev mode on "localhost:3000" with proxy set to connecting api port "9090"
When I try to connect to "localhost:3000", I always get the following error:
Failed to load http://localhost:9090/login: Redirect from 'http://localhost:9090/login' to 'http://localhost:8080/oauth/authorize?client_id=acme&redirect_uri=http://localhost:9090/login&response_type=code&scope=read%20write&state=qbV8P2' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.
If I run "yarn build" and let spring boot serve the frontend static files, then if I access "localhost:9090", I will be properly redirected to the login page from the oauth2 server.
I've tried to allow "localhost:3000" by editing cors mapping from spring boot but this problem is still here.
As a side note, If I get authenticated by accessing "localhost:9090", and acquired the session cookie, then I can access protected resource by using "localhost:3000". It's just if I am not authenticated in the first place, then instead of being redirected to the login page, I always get the CORS error.
Any help would be appreciated.
CORS is basically a way to determine if it is safe to grant access to restricted resource on a web page when requested from another domain. I am not sure, how does it works when you let spring boot serve your frontend static files. But you would simply have to grant permissions to your frontend server at http://localhost:3000 to access restricted resources at http://localhost:8080.
For e.g., if your request header looks like following:
Access-Control-Allow-Origin:http://localhost:3000
Access-Control-Request-Method: POST
Access-Control-Request-Headers: <your custom headers>
Then, server rules must be:
Access-Control-Allow-Origin:http://localhost:3000
Access-Control-Request-Method: POST, GET, DELETE, PUT
Access-Control-Request-Headers: <your custom headers>
Please note that keeping any parameter as * won't work.
Please let me know if it helps!
when trying to $.ajax to fetch some content from other websites in my website, I got the error.
Failed to load https://www.pinterest.com/: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8100' is therefore not allowed access.
I knew if the target website didn't allow localhost:8100 to fetch the data, I cannot fetch it in the client side on the web.
However, I found that mobile app (not mobile browser, but android/ios application) does not have the issue, they can simply get the website content by their default mobile built-in HTTP get function.
Do i want to ask why mobile will not encounter CORS issue (mobile can fetch the webcontent simply by the built-in http get function)?
thanks.
CORS is enforced by the browser to fulfill the security standard they have to meet. It does not affect requests made programmatically from any language, like a curl call on bash.
This is how CORS works, based on Wikipedia:
The browser sends the OPTIONS request with an Origin HTTP header. The value of this header is the domain that served the parent page. When a page from http://www.example.com attempts to access a user's data in service.example.com, the following request header would be sent to service.example.com: Origin: http://www.example.com.
The server at service.example.com may respond with:
An Access-Control-Allow-Origin (ACAO) header in its response indicating which origin sites are allowed. For example Access-Control-Allow-Origin: http://www.example.com
An error page if the server does not allow the cross-origin request
An Access-Control-Allow-Origin (ACAO) header with a wildcard that allows all domains: Access-Control-Allow-Origin: *
The way CORS works means it is optional. Browsers enforce it to prevent Javascript AJAX calls to perform malicious calls. But other types of consumers built by hand don't need to enforce CORS.
Think in this example:
You are the owner of somesite.com
Users authenticate to your site using the traditional cookie method
User logins into anothersite.com, built by an attacker. This site has the following code:
<script>fetch('http://somesite.com/posts/1', { method: 'DELETE' });</script>
... effectively performing a request to your site and doing bad things.
Happily, the browser will perform a preflight request when it sees a cross-domain request, and if your site does not respond saying that requests coming from anothersite.com are OK, you will be covered by default from a potential attack
This is why CORS only makes sense in the context of a browser. Javascript you send to the browser can not (at least easily) circumvent CORS because the only API that allows you to perform requests from the browser is written in stone. Additionally, there are no local storage or cookies outside of the browser.
Corolarium: Enforcing CORS is a deliberate action from the requester, or whoever is making the requests for you, not the sender. Javascript APIs in browsers enforce it. Other languages don't have the need for the reasons explained.
When running on a device, your files are served over the file:// protocol, not http://, and your origin will therefore not exist. That's why the request from the native device does not trigger CORS.
I followed the instructions found in the readme in the stormapth-sdk-react github respository to set up a basic login form. The form displays, but I am immediately greeted by errors in the console:
XMLHttpRequest cannot load https://{redacted}.apps.stormpath.io/me. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. The response had HTTP status code 403.
I get an identical error for the login endpoint.
The Client API Guide indicates that client endpoints have to be configured to allow traffic from a particular domain, but does not provide any instructions for how to do this:
Applications that use the Client API have two relevant configuration parameters, both found on your Application’s page in the Stormpath Admin Console:...
Authorized Callback URIs: This list should include any URIs that your users will be returned to after they have completed authentication with an outside provider, for example as a part of the social login flow. For example, if you do not specify a redirect URI when you kick off the social login flow, the user will be redirected the first URI in this list.
Authorized Origin URIs: This list should include the application’s URL, or whatever URL will be included in the Origin header of requests sent to the Client API.
What do I need to do to get this working?
To fix this, you can login to https://api.stormpath.com, navigate to Applications > My Application, and modify the Authorized Origin URIs to include http://localhost:3000.
Stormpath seems to use a pretty similar setup to many API services. Like the directions say, go to your Stormpath Admin Console, and put your hostname (http://localhost:3000) in the relevant fields for both 1. and 2.
Doing so tells the Stormpath API to allow data to be sent to your application.
The Cross-Origin Resource Sharing (CORS) mechanism gives web servers cross-domain access controls, which enable secure cross-domain data transfers.
As the server you are using (for react) differs from the server you are requesting data(node or something else). (even the subdomain or port matters)
index.js: (server)
const cors = require('cors');
..
..
app.use(cors());
for more info about using cors: npm cors
I'm encountering a pretty strange issue in IE11 where the browser is overriding the Authorization header in my requests even though I am setting it via AngularJS.
Basically, I have an HTTP interceptor registered for all requests that looks like this:
AuthInterceptorService.request = function (config) {
config.headers.Authorization = "Bearer " + bearerToken;
}
This works great in all browsers (even IE under certain conditions). I have my app set up in IIS as allowing anonymous authentication and I have basic/integrated authentication disabled for this subsite, however, the parent configuration has windows authentication eabled.
What is happening occasionally is that the browser will make a request to the root URL for a static file (say, /favicon.ico). This request is denied with a 401. The browser responds with negotiated authentication and gets the favicon. At this point, all other browsers still let my code set the Authorization header, but once this integrated authentication happens in IE, the authorization header seems to get stuck - no matter what my code does, the authorization header is always using integrated authentication. This causes all requests to my API to fail because no Bearer token is present.
I was able to work around the favicon issue by specifying a more local favicon (where static files can be served anonymously), but I am wondering if there is a less hacky solution to this issue. Can I somehow convince IE to let me set the Authorization header even if Windows authentication has taken place on a previous request?
Note: I found this question which seems to be related (maybe the same underlying cause).
If you look at the Negotiate Operation Example of the RFC 4559 document, it involves a pseudo mechanism used by IE to negotiate the choice of security when authenticating with IIS.
The first time the client requests the document, no Authorization
header is sent, so the server responds with
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Negotiate
The client will obtain the user credentials using the SPNEGO GSSAPI
mechanism type to identify generate a GSSAPI message to be sent to
the server with a new request, including the following Authorization
header:
C: GET dir/index.html
C: Authorization: Negotiate a87421000492aa874209af8bc028
The server will decode the gssapi-data and pass this to the SPNEGO
GSSAPI mechanism in the gss_accept_security_context function. If the
context is not complete, the server will respond with a 401 status
code with a WWW-Authenticate header containing the gssapi-data.
S: HTTP/1.1 401 Unauthorized
S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356
The client will decode the gssapi-data, pass this into
Gss_Init_security_context, and return the new gssapi-data to the
server.
So, I don't think its possible for you to intermingle while the negotiation takes place as the process is internal