React axios request blocked by CORS policy when deployed to server - api

Ok, I hope I am not making a duplicate but my question is a bit different from most of the result for CORS questions.
I have springboot rest api backend and I have reactJs frontend using Axios.
on my API interface I added
#CrossOrigin(origins = {"http://localhost:3000", "http://localhost"})
#RequestMapping ...
...
Locally everything is running fine.
React running on http://localhost:3000
api running on http://localhost:8080/apixxx/orders
So I deployed them on my ubuntu server:
React running on http://12.123.12.123 (port is 80)
api running on http://12.123.12.123:8080 (postman requests are successful)
Now see, I put #CrossOrigin origin of "http://localhost" because that is for the deployed copy of my API, since relative to the server it is localhost.
Now I am getting:
Access to XMLHttpRequest at 'http://localhost:8080/apireq/v1/apiresourcexx' from origin 'http://12.123.12.123' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
this is the same error I get locally when I remove the #CrossOrigin.
I tried adding in the origins "http://12.123.12.123", "http://12.123.12.123:80", "http://myDomainName.com" (my domain name), "http://myDomainName.com:80".
Nothing works. Still the same error.
What I found works is:
#CrossOrigin(origins = {"*"})
But I dont want to do that....
Please help.
-----UPDATE-----
Ok, I am really confused now.
Apparently, I just realized that the axios routing I used is axios.post('http://localhost:8080/apixxx/orders', ...); And basically this will point to the springboot running on my local machine, not on the prod server. If that is the case, then each of my client will be different origin and all of them will be calling my API... If that is the case then the only solution is that one I am avoiding: #CrossOrigin(origins ="*")
Please advise. What do you guys usually do in this situaion.

Related

identity server multiple issues after deployment

My current setup is like this. The entire project was built using the official docs here - https://identityserver4.readthedocs.io/en/latest/
API Server
Auth Server with local login, google login and github login
Console based c# client
JS based client
MVC based client.
(all of it, as described in the official docs)
Locally, all of them work beautifully. Able to login, access api endpoints, logout, redirect, the whole thing works smooth.
I have deployed all 5 of them to five different azure web apps. They all have the standard xyz.azurewebsites.net domains ready to use. Now, I have run into some problems.
the console C# client is able to talk to the deployed auth server, collect token using a local account on the auth server and make calls to the deployed API server. Based on this, I assume that both the api server and the auth server working hand in hand, as they should.
Problem #1 - the JS client keeps saying
'The login is blocked because of CORS Missing Allow Origin '
Problem #2 - the MVC client loads the auth server, and then the auth server gives me this error.
Sorry, there was an error : unauthorized_client
Request Id: 80005c0f-0000-eb00-b63f-84710c7967bb
Note : I have set the CORS policy on the auth server, both these clients, under client definition as follows. I am not too concerned about keeping the auth server open, so dont mind if any and every domain can call the auth server.
AllowedCorsOrigins = { "*.*" },
Also Note : I have set the URLS in the code before deployment. all loclahost:port number lines have been replaced correctly with the corresponding now published URLs.
So, what am I missing out here?
Update 1
I was able to solve the CORS issue. Have posted a answer here on another question.
Not able to enable CORS for identity server 4 in asp.net core
Update 2
So, now, both the JS client and the MVC client, are giving identical errors.
Sorry, there was an error : unauthorized_client
Request Id: 80005c0f-0000-eb00-b63f-84710c7967bb
Update 3
I have opened an issue which has log details.
https://github.com/IdentityServer/IdentityServer4/issues/4691
I am not sure if this counts as an answer, but posting for my own question, as it might might help others. Also, this is only a guess at this point.
I found out that the redirects were permanently stored in the database I used with EF migrations. That mean, local in memory redirects were being overwritten anyway by the database stored migrations. I believe this is the issue.
I also realized that the console app is working fine for it does not depend on redirect URLs where as the JS and MVC based clients dont work because they do depend on redirect URLs.
At this point, the best thing to do and for you (if you used EF migrations to store your auth server configuration) on database would be start over and switch to in memory only. Alternatively, you can try and update the database to suit your deployment requirements.
Ultimately, I believe, unless it is absolutely necessary, keep the auth server config (like redirects and CORS settings) in memory as they dont take up much value and are rarely changed.

Google OAuth & API: blank login because localhost is not "whitelisted"

Error (inspected from html):
details: "Not a valid origin for the client: http://localhost:3000 has not been whitelisted for client ID 830959654564-inlhib5r4afjbm4ebt1e43gt07bpvve5.apps.googleusercontent.com. Please go to https://console.developers.google.com/ and whitelist this origin for your project's client ID."
error: "idpiframe_initialization_failed"
Problem:
Tried using localhost:3000 and my local ip address given from React.
I've tried clearing the cache. I've tried using other browsers.
Blank Google OAuth
Well still no real solution but I created a new project and have reached no problems yet.
For me, this only worked when I created a project directly from https://console.developers.google.com/.
The project I created "inline" at https://developers.google.com/identity/sign-in/web/sign-in never seemed to see the origin config.

Cross Domain Error Worklight Adapter Request

I'm trying to make a GET request from an iPhone app(built on Worklight), to a remote worklight adapter on a remote server.
I have generated the authorization request header using the following
http://remote-url:port/project/authorization/v1/testtoken
However, I keep getting the following cross domain error:
XMLHttpRequest cannot load https://remote-url/project/adapters/call/mq/getAccounts/22. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://myapp-url:port' is therefore not allowed access.
But, when I try do the same GET request using an API tool like Postman, I receive the results no issues on my browser.
First - testtoken is only available from the MobileFirst Studio development environment... you need to take this into consideration.
Second, you're likely using Chrome and Crome disallows CORS by default. Change your browser settings and/or try in a different browser.

Bigcommerce authentication get request only returns scope and code, context is missing

I am kicking off the Bigcommerce app installation process by following the instructions given in this official documentation page https://developer.bigcommerce.com/api/callback apparently I am following every thing. I have https Auth Callback url setup in the app configuration page
NOTE: I am using ngrok to tunnel my localhost to internet.
When Install my app I receive the code and scope objects in the Get Request but not the context object.
Please help me with what did I missed ? and how I can get the context object ?
UPDATE
I tested it without ngrok and its the same.

Using stomp.js over sock.js with ActiveMQ-Apollo does not seem to work

I am working through some samples in the ActiveMQ-Apollo installation and playing around with the examples/websocket.
In this file, Stomp.js is being used to establish connection:
client = Stomp.client(url);
The example works fine and I am able to see the messages being sent and received. The issue, is that Stomp uses default WebSocket which may not be available at times. So, I wanted to integrate with SockJS client library. According to the example for StompJS on this page (http://jmesnil.net/stomp-websocket/doc/) it should be possible with this code:
<script src="http://cdn.sockjs.org/sockjs-0.3.min.js"></script>
<script>
// use SockJS implementation instead of the browser's native implementation
var ws = new SockJS(url);
var client = Stomp.over(ws);
[...]
</script>
The above code appears to execute correctly, however, later I see the following errors:
XMLHttpRequest cannot load ws://mylocaldomain.com:61623/info. Cross origin requests are only supported for HTTP. sockjs-0.3.js:807
Uncaught Error: NetworkError: DOM Exception 19
Then, I see the debug window show this message:
Opening Web Socket...
Whoops! Lost connection to undefined
I am serving the page from mylocaldomain.com:80, and the ActiveMQ Apollo server is running on the same machine, but listening on port 61623. I have also grabbed the latest version of StompJS (from dist directory on github) as well as SockJS directly from cdn.sockjs.org.
I tried this example on latest Chrome and Firefox (on OSX) and the same thing occurs. No connection is established.
Again, going back to the standard example which ships with the Apollo works fine, but I would like to find out why StompJS over StockJS is failing.
Has anyone seen this issue?
Thanks.
-AP_
You need to modify the ActiveMQ-Apollo web configuration to support Cross-Origin-Resource-Sharing (CORS) as described here:
Enabling CORS
W3C CORS Specification
Basically the server needs to do the following things:
Support the HTTP OPTIONS request (aka CORS pre-flight request) that is sent by browsers for Cross Domain requests. This includes responding to the OPTIONS request with:
Access-Control-Allow-Origin header (for example: "*" which means allow all origins)
Access-Control-Request-Method header (for example: "GET, POST, PUT, DELETE, OPTIONS")
Access-Control-Allow-Headers (for example: "X-Requested-With,Origin,Content-Type, Accept")
The handling of HTTP OPTIONS can typically be done using a single Web Filter matching filter pattern "/*".
See also "cors_origin" WebSocket connector URL query parameter supported by ActiveMQ Apollo 1.7