I am making a Cordova application. I need to make a simple GET request with Angular.
I keep getting the message:
"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://myserver/AuthenticateMe. This can be fixed by moving the resource to the same domain or enabling CORS."
I thought I added all the necessary headers to my response. Here is the full header:
"Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Origin: *
Content-Encoding: gzip
Content-Length: 76
Content-Type: application/json;charset=UTF-8
Date: Mon, 16 Mar 2015 21:37:56 GMT
Server: Apache-Coyote/1.1"
I tried this in Firefox and Chrome.
This is extremely annoying because I never had a problem with my server when I was doing native iOS and Android requests.
Am I missing anything here???
Did you try jsonp?
Something like:
$http.jsonp(API_URL + "/?callback=JSON_CALLBACK")
.success(function(data) {
// blah blah
})
.error(function() {
console.log("couldn't fetch.");
})
.finally(function() {
// blah blah
});
Guessing, but I think you also need to specify which HTTP verbs you want to allow for CORS.
Access-Control-Allow-Methods: *
or
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Related
I have troubles with CORS error.
I am developing a react app with create-react-app.
I am using axios to fetch data from BE but when I try to fetch I got cors error in chrome:
I tried to disable CORS policy in chrome but nothing is working.
Is very strange because the login route works while the other routes that need a session in header are not working. I tried also to call them through command line CURL and they work as expected.
With the curl command line I dumped the response header and I got:
HTTP/1.1 200
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Access-Control-Allow-Origin: *
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Type: application/json
Transfer-Encoding: chunked
Date: Tue, 12 Oct 2021 13:22:07 GMT
My frontend is in http://localhost:3000 while the backend is in another domain on internet.
What am I doing wrong?
You could either proxy the backend or request the backend to add CORS headers, like Access-Control-Allow-Origin, Access-Control-Allow-Methods,
Access-Control-Allow-Headers
Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
I solved the problem enabling (in BE part) the following headers:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Max-Age: 3600
Access-Control-Allow-Headers: *
Adding these, the preflight calls succeded and I was able to fetch the API
Now I am writing a simple server on Go using the standard library net/http. The server is placed in a docker container and placed on google cloud paltform. But when I want to access the server from my third-party React application (which is located on a different server), I always get a CORS error.
Looking for solutions online, I added a library to my code, which is designed to solve the problem of СORS. But adding a library didn’t help. Even after its application, the server does not send me СORS headers. What code do I have now?
package main
import (
controller "./controllers"
"./util"
"github.com/gorilla/mux"
"github.com/rs/cors"
"log"
"net/http"
//"os"
)
// Entry point
func main() {
c := cors.New(cors.Options{
AllowedOrigins: []string{"*"}, // All origins
AllowedMethods: []string{"GET"}, // Allowing only get, just an example
AllowedHeaders: []string{"Authorization", "Content-Type"},
AllowCredentials: true,
Debug: true,
})
r := mux.NewRouter()
// Router
// Live check
r.HandleFunc("/live", controller.LiveCheck)
apiRouter := r.PathPrefix("/api").Subrouter()
// Medication data
medicationRouter := apiRouter.PathPrefix("/medication").Subrouter()
medicationRouter.HandleFunc("", controller.MedicationHeadersList).Methods("GET")
medicationRouter.HandleFunc("/{id}", controller.MedicationChildrenList).Methods("GET")
medicationRouter.HandleFunc("/{id}/leafs", controller.MedicationLeafsList).Methods("GET")
medicationRouter.HandleFunc("/search/", controller.SearchMedicationList).Methods("GET")
medicationRouter.HandleFunc("/result/{id}", controller.MedicationSearchResult).Methods("GET")
//r.Use(util.CORS)
apiRouter.Use(util.VerifyToken)
log.Println(http.ListenAndServe(":8080", c.Handler(r)))
}
Here is the answer I get from the up-point in the browser console:
Request Method: OPTIONS
Status Code: 200 OK
Remote Address: 35.190.37.37:80
Referrer Policy: no-referrer-when-downgrade
Content-Length: 0
Date: Mon, 10 Jun 2019 22:37:36 GMT
Vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
Via: 1.1 google
I also tried to manually set the CORS headers, creating a middleware, but it also did not help.
Thanks in advance for your help!
UPD Thank you all for the answers and help. Everything turned out to be much easier. Google did not update my docker container, so all my changes in the code did not give the desired effect. My code, which I gave in the question description, perfectly solves the problem of the CORS. The question can be considered closed.
I had this problem too. You can use this code in the development environment.
c := cors.New(cors.Options{
AllowedOrigins: []string{"*"},
AllowCredentials: true,
AllowedHeaders: []string{"Authorization", "Content-Type", "Access-Control-Allow-Origin"},
// Enable Debugging for testing, consider disabling in production
AllowedMethods: []string{"GET", "UPDATE", "PUT", "POST", "DELETE"},
Debug: true,
})
How are you testing this? When a browser must make a cross-origin request that fails pre-flight conditions an OPTIONS request gets sent. This OPTIONS request contains a header who's value is the HTTP method being used in the cross-origin request.
I stood up your simplified version of your server and here's some example curl commands and results.
The below request works fine, I've set the Access-Control-Request-Method to GET
curl -I -X OPTIONS -H "Origin: test.com" -H "Access-Control-Request-Method: GET" http://localhost:8080/
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: *
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Date: Tue, 11 Jun 2019 02:20:35 GMT
Content-Length: 0
The below request doesn't work without the Access-Control-Request-Method header. Our server may have different CORS settings for GET and POST (etc..), and our server can't communicate that to the client. The client must set the Access-Control-Request-Method header so the server knows how to properly respond.
curl -I -X OPTIONS -H "Origin: test.com" http://localhost:8080/
HTTP/1.1 200 OK
Date: Tue, 11 Jun 2019 02:31:12 GMT
Content-Length: 436
Content-Type: text/html; charset=utf-8
I have an AngularJS web app that accesses a .NET WebAPI server end. Authentication is implemented through the AngularJS-OAuth2 library. I have the app and the WebAPI hosted in localhost under two different port numbers. I have also enabled Microsoft.Owin.Cors package on the server end to handle cross-domain requests.
In Chrome, GET and POST requests return data to the front-end. By inspecting the traffic through Fiddler I could see that a pair of requests/responses are sent (preflight/OPTIONS + actual) and also the relevant CORS headers (including origin and Access-Control-* headers) in both the requests and the responses. All as expected.
However, in Internet Explorer, my GET requests return data through the $http service but the POST does not. I could inspect that there are no preflight requests or CORS headers (I think IE treats different ports as the same origin). In checking the POST request/response in IE through Fiddler I could observe that it returns HTTP status 200 but state of Aborted (with X-ABORTED-WHEN: SendingResponse flag set). I could also inspect the JSON response with the correct data returned.
I have also tried setting a high timeout to no avail. The $http call looks like this:
return $http.post(apiUrl + "/search", service.getParameters(), { timeout: 600000 })
.success(function (data) {...
Fiddler shows something like this for the IE POST request:
Also (only) in IE, an unintentional page refresh is also triggered with the same button click as this POST operation.
Why does Internet Explorer abort only the POST requests when the correct data is also returned to the client and when Chrome does not have any issues at all?
Additional Information
Request:
POST https://localhost:44321/api//search HTTP/1.1
Content-Type: application/json;charset=utf-8
Accept: application/json, text/plain, */*
Authorization: Bearer <token>
Referer: https://localhost:44322/search
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: localhost:44321
Content-Length: 202
DNT: 1
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: .ASPXANONYMOUS=<cookie>
Reponse:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: <file>
X-Powered-By: ASP.NET
Date: Wed, 10 Feb 2016 13:43:45 GMT
Content-Length: 2284
Fiddler session properties:
SESSION STATE: Aborted.
Request Entity Size: 202 bytes.
Response Entity Size: 2284 bytes.
== FLAGS ==================
BitFlags: [IsHTTPS, ClientPipeReused, ServerPipeReused] 0x19
X-ABORTED-WHEN: SendingResponse
X-CLIENTIP: 127.0.0.1
X-CLIENTPORT: 41889
X-EGRESSPORT: 41890
X-HOSTIP: ::1
X-PROCESSINFO: avp:3584
X-RESPONSEBODYTRANSFERLENGTH: 2,284
X-SERVERSOCKET: REUSE ServerPipe#168
== TIMING INFO ============
ClientConnected: 19:13:42.408
ClientBeginRequest: 19:13:42.444
GotRequestHeaders: 19:13:42.444
ClientDoneRequest: 19:13:42.772
Determine Gateway: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 0ms
HTTPS Handshake: 0ms
ServerConnected: 19:13:42.413
FiddlerBeginRequest: 19:13:42.772
ServerGotRequest: 19:13:42.772
ServerBeginResponse: 19:13:45.360
GotResponseHeaders: 19:13:45.360
ServerDoneResponse: 19:13:45.360
ClientBeginResponse: 19:13:45.360
ClientDoneResponse: 19:13:45.360
Overall Elapsed: 0:00:02.915
The response was buffered before delivery to the client.
== WININET CACHE INFO ============
This URL is not present in the WinINET cache. [Code: 2]
* Note: Data above shows WinINET's current cache state, not the state at the time of the request.
* Note: Data above shows WinINET's Medium Integrity (non-Protected Mode) cache only.
I believe you get bitten by the P3P policy requirement of IE here:
Internet Explorer supports a cookie-restricting privacy feature called P3P. Web developers often get tripped up by it because no other browser implements the P3P standard.
It seems similar to those QAs:
CORS request with IE11
CORS doesn't work with cookies in IE10
Internet Explorer 10 is ignoring XMLHttpRequest 'xhr.withCredentials = true'
Here's a blog post with an example how to send P3P information. Here's a document from Microsoft about P3P configuration
I've built an API to use for local auth and Facebook auth.
I'm using node, express, passport and oauth2orize for the authorization process.
I'm now running the API perfectly through terminal applications and API testing suites, however, when making calls to my authentication endpoints from angular I receive the following:
Local auth:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at
http://localhost:4200/oauth2/auth
?client_id=[CLIENT_ID]
&redirect_uri=http:%2F%2Flocalhost:4200%2Foauth2%2Fauth%2Fcallback (http://localhost:4200/oauth2/auth/callback)
&response_type=code.
This can be fixed by moving the resource to the same domain or enabling CORS.
Facebook auth:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at
https://www.facebook.com/dialog/oauth
?response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%3A4200%2Fauth%2Ffacebook%2Fcallback (http://localhost/auth/facebook/callback)
&client_id=[CLIENT_ID].
This can be fixed by moving the resource to the same domain or enabling CORS.
I have had CORS issues in the past and integrated the npm 'cors' middleware module found at https://www.npmjs.com/package/cors
CORS init:
var cors = require('cors');
api.use(cors());
With my previous issues, this was sufficient, however, with these new CORS issues it's not helping.
I've also noticed, in Firefox, if I click on the error message, a new dialog window opens up as it should and the server continues to correctly authorize the user.
Could anyone help?
UPDATE 1:
Check comments for screenshot of debug info.
UPDATE 2:
Response headers for the last 2 requests performed in the login flow.
204:
Access-Control-Allow-Credentials: true
Connection: keep-alive
Date: Fri, 06 Feb 2015 15:26:43 GMT
Vary: Origin
X-Powered-By: Express
access-control-allow-headers: authorization
access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE
access-control-allow-origin: http://localhost:8100
302:
Access-Control-Allow-Credentials: true
Connection: keep-alive
Content-Length: 138
Content-Type: text/plain; charset=utf-8
Date: Fri, 06 Feb 2015 15:26:43 GMT
Location: http://localhost:4200/oauth2/auth/callback?code=[CODE_HERE]
Set-Cookie: connect.sid=[SID_HERE]; Path=/; HttpOnly
Vary: Origin, Accept
X-Powered-By: Express
access-control-allow-origin: http://localhost:8100
The earlier examples in the docs don't include handling the preflight request, and do not specify any origins, which is required if you want to send any credentials with the requests (for example, your authorization header). Here's an example:
var whitelist = ['https://localhost:4200']; // Acceptable domain names. ie: https://www.example.com
var corsOptions = {
credentials: true,
origin: function(origin, callback){
var originIsWhitelisted = whitelist.indexOf(origin) !== -1;
callback(null, originIsWhitelisted);
// callback(null, true); uncomment this and comment the above to allow all
}
};
// Enable CORS
app.use(cors(corsOptions));
// Enable CORS Pre-Flight
app.options('*', cors(corsOptions));
It might be just angularjs issue! I am very new to the frontend and angularjs.
I have an angularjs sign in service which calls the url '/signin/facebook/' to sign in, it seems the backend is redirected correctly and calling the facebook oauth but I got the follow error.
[Angularjs sign in service]
app.factory('fbSigninService', function($http){
return{
fb_signin:function(scope){
var $promise=$http.post('/signin/facebook/',JSON.stringify(scope));
}
}
});
[error]
XMLHttpRequest cannot load https://www.facebook.com/v1.0/dialog/oauth?client_id=xxxxxxxxxxxxxxx&respon…t%3A8080%2Fsignin%2Ffacebook%2F&state=12431991-7555-4ed4-90b9-728e11c721f0. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access.
so when I click on the link directly from the browser's console from the error, it authenticated fine!
https://www.facebook.com/v1.0/dialog/oauth?client_id=xxxxxxxxxxxxxxx&respon…t%3A8080%2Fsignin%2Ffacebook%2F&state=12431991-7555-4ed4-90b9-728e11c721f0
Update #01
I don't think, javascript suppose to call the facebook auth, the javascript should call the same host '/signin/facebook/' and then the backend should make the facebook auth call???
Update #02 15/Oct/2014
1) I have updated the code to allow cross origin but still getting the same error.
2) when I re-read the error again, it actually saying "facebook"'s doesnt' have 'Access-Control-Allow-Origin' header is present on the requested resource.
So the question is, how am I supposed to call from angularjs -> java api -> redirect to facebook login page?
[Java]
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
response.setHeader("Access-Control-Max-Age", "3600");
response.setHeader("Access-Control-Allow-Headers", "x-requested-with");
[Headers]
Request URL:http://localhost:8080/index.html
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:JSESSIONID=3BA4D9DBF38686F2AA527BF408D28EC1
Host:localhost:8080
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/31.0.1650.63 Chrome/31.0.1650.63 Safari/537.36
Response Headersview source
Access-Control-Allow-Headers:x-requested-with
Access-Control-Allow-Methods:POST, GET, OPTIONS, DELETE
Access-Control-Allow-Origin:*
Access-Control-Max-Age:3600
Cache-Control:no-cache, no-store, max-age=0, must-revalidate
Content-Length:1839
Content-Type:text/html
Date:Wed, 15 Oct 2014 23:15:01 GMT
Expires:0
Last-Modified:Wed, 08 Oct 2014 22:10:40 GMT
Pragma:no-cache
Server:Apache-Coyote/1.1
X-Application-Context:application
X-Content-Type-Options:nosniff
X-Frame-Options:DENY
X-XSS-Protection:1; mode=block
Update #03
I am using the Advance REST client to call the '/signin/facebook/', it seems working fine.
Redirect #1
To:https://www.facebook.com/v1.0/dialog/oauth?client_id=273118692865062&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fconnect%2Ffacebook&state=00d8c7ee-e178-4d2b-bc86-500505d5eac2 with status: 302 Show explanation HTTP/1.1 302 Found
Redirection information has not been cached.
Server: Apache-Coyote/1.1
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 3600
Access-Control-Allow-Headers: x-requested-with
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
X-Application-Context: application
Location: https://www.facebook.com/v1.0/dialog/oauth?client_id=273118692865062&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fconnect%2Ffacebook&state=00d8c7ee-e178-4d2b-bc86-500505d5eac2
Content-Language: en-US
Content-Length: 0
Date: Thu, 16 Oct 2014 21:50:21 GMT
Redirect #2
To:http://localhost:8080/connect/facebook?code=AQCq9wnl_LeecAuWkR0D2252YZICiuWiaFeSUqISaUzQ7vfHHWI1sMsqSWO5kpgUQG0URi5NI52UX3zBpKTwj7rnnzQKOnxjUbyxwN-Z3a3rt1G3P84ONaCrsUO-LuM0_bpvROzWzno0pK9_lf-KI5JhqBvWWRGuWGEKz1FKl816rbrEP_nmh97BBM5oW3IYbvjuhKSghINp2ilADgLabMFTC76zN41HRjWE7X1bXGLaXY3EtQG61R5FGo7QV-W9iWtH3PCZw4gP_DByiDdUrObo1OsECWSkdh6q7a-EsuJ_QZe5zqQJbhEf2GHal5AC9YU&state=00d8c7ee-e178-4d2b-bc86-500505d5eac2#_=_ with status: 302 Show explanation HTTP/1.1 302 forced.302
Redirection information has not been cached.
status: 302 forced.302
version: HTTP/1.1
cache-control: private, no-cache, no-store, must-revalidate
content-length: 0
content-security-policy: default-src *;script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net *.atlassolutions.com chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl;style-src * 'unsafe-inline';connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net wss://*.facebook.com:* ws://*.facebook.com:* http://*.akamaihd.net https://fb.scanandcleanlocal.com:* *.atlassolutions.com http://attachment.fbsbx.com https://attachment.fbsbx.com;
content-type: text/html; charset=utf-8
date: Thu, 16 Oct 2014 21:50:21 GMT
expires: Sat, 01 Jan 2000 00:00:00 GMT
facebook-api-version: v1.0
location: http://localhost:8080/connect/facebook?code=AQCq9wnl_LeecAuWkR0D2252YZICiuWiaFeSUqISaUzQ7vfHHWI1sMsqSWO5kpgUQG0URi5NI52UX3zBpKTwj7rnnzQKOnxjUbyxwN-Z3a3rt1G3P84ONaCrsUO-LuM0_bpvROzWzno0pK9_lf-KI5JhqBvWWRGuWGEKz1FKl816rbrEP_nmh97BBM5oW3IYbvjuhKSghINp2ilADgLabMFTC76zN41HRjWE7X1bXGLaXY3EtQG61R5FGo7QV-W9iWtH3PCZw4gP_DByiDdUrObo1OsECWSkdh6q7a-EsuJ_QZe5zqQJbhEf2GHal5AC9YU&state=00d8c7ee-e178-4d2b-bc86-500505d5eac2#_=_
pragma: no-cache
strict-transport-security: max-age=15552000; preload
x-content-type-options: nosniff
x-fb-debug: ESLliRqmaFv9DBXraKZN4X3FRH36D8lnMegz7e9Udqv5aECkJwU7DiWbQ+g+d9X4G+30cP27b3nCs9BsDIlM6w==
x-frame-options: DENY
x-xss-protection: 0
Redirect #3
To:http://localhost:8080/connect/facebook#_=_ with status: 302 Show explanation HTTP/1.1 302 Found
Redirection information has not been cached.
Server: Apache-Coyote/1.1
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 3600
Access-Control-Allow-Headers: x-requested-with
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
X-Application-Context: application
Location: http://localhost:8080/connect/facebook
Content-Language: en-US
Content-Length: 0
Date: Thu, 16 Oct 2014 21:50:21 GMT
Though am late but I think it can help to an extent.
Spring-social APIs handle all this out of the box. I have created a sample app which uses Spring-social and AngularJS. Its a very basic flow but may help.
spring-social-angularjs-sample
You need to allow requests to outside of your domain (this is a security mechanism enforced by your browser which blocks by default requests to foreign domain addresses - read).
you probably need to configure a rule to allow your client to access Facebook - needs to be added in your server's configuration (not in angular)
how to fix? - django, node, apache, iis, ...
The issue is with cross-origin requests, not the authentication itself. There is no specific configuration in spring social or security modules to handle facebook or any other provider. Answering one of your doubts - yes, the backend should handle all of the dance, you do not have to do anything from your front-end apart from calling the authentication address.
At first, try to authenticate through your server against facebook API by doing the same call as you do from your angular client but using Advanced REST client for Chrome. See the outcome.
Then, I would start with proper implementation of CORS filters in your case. To test that CORS is working at least to some extent, create a controller to handle a POST request and send one from Angular. Test it first without using the Facebook API. If you cannot send a POST, this means you have to change your CORS filters before you proceed with using facebook API for authentication.
If your simple POST works (or, moreover, if it doesn't) please refer to Tomcat documentation for the catalina implementation of Cors Filter http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter . They provide sample configuration of filters which should allow you to get rid of any cors issues (you can add one more header to the cors allowed headers, "Authorization").
If none of these above help you, let me know.