XMLHttpRequest cannot load No 'Access-Control-Allow-Origin' header is present on the requested resource

[gateway]

Not sure exactly what the issue is here, I have a Heroku server setup with mongolab db connected, the server is up and running but Im unable to save any data to the server since it spits out this in my console.

Here is the code im using on another server..

[rudymacias]

Had the same issue and got it fixed! Here is the code I placed right after the "api" variable in the index.js file:

app.all('*', function(req, res, next) {
    res.header('Access-Control-Allow-Origin', '*');
    res.header('Access-Control-Allow-Methods', 'PUT, GET, POST, DELETE, OPTIONS');
    res.header('Access-Control-Allow-Headers', 'accept, content-type, x-parse-application-id, x-parse-rest-api-key, x-parse-session-token');
     // intercept OPTIONS method
    if ('OPTIONS' == req.method) {
      res.send(200);
    }
    else {
      next();
    }
});

It's not final, just got me thru to be able to make calls from JS app

[gfosco]

Strange, because we enable this already here: https://github.com/ParsePlatform/parse-server/blob/master/index.js#L90

[gateway]

@rudymacias hmm thanks.. not sure why its just not working like suggested above.. just so you know, I set up a heroku parse server with the parse server example, connected to MongoLab.

@gfosco I just tried this again with a fresh install of the parse server example on Heroku + MongoLabs.. ran the code and got the same result.. any thoughts or how I could help debug this?

from the Heroku deployment..

remote: -----> Build succeeded!
remote: ├── express@4.2.0
remote: ├── kerberos@0.0.18
remote: ├── parse@1.6.14
remote: └── parse-server@2.0.3

[gfosco]

Ahhhh... In the screenshot above, the path is missing.. xxx.herokuapp.com/parse (or whatever your mount point is.. defaults to /parse.

[gateway]

@rudymacias

Ok adding this code worked..

Now just getting a 404.. not sure whats up, do I need to populate some basic database collections in mongoLab first?

[rudymacias]

Nice! Yeah right you probably need data in the Database. At least a class setup. But after data is there, I haven't had any problem making requests to find/create.

[gfosco]

See my comment above, you don't need data, but you do need to provide the right path as the serverURL.

[gateway]

Yea, I just posted on a similar issue , might be worth updating docs.. i know its silly but could keep questions like this from cropping up.. thank you..

[VesperDev]

on the route you put in Parse.serverURL add / parse to avoid that mistake

[Srj-Love]

http://srjlove.iran-rank.ir/wc-api/v3/products/categories?oauth_consumer_ke…version=1.0&oauth_signature=zDbvUd5nkxqyDtTvvTwfPvjytNRWK9xLoZZvAlBDuI0%3D. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://192.168.0.101:8100' is therefore not allowed access.

what is an error in this

.config(function($stateProvider , $urlRouterProvider)
{
$stateProvider
.state('app' ,
{
url: '/app',
templateUrl: 'templates/menu.html',
controller: 'AppCtrl',
abstract: true
})
.state('app.home', {
url: '/home',
views:
{
'menuContent' :
{
templateUrl: 'templates/home.html',
controller: 'HomeCtrl'
}
}
});

$urlRouterProvider.otherwise('/app/home');
})

.controller('AppCtrl', function($scope, WC){

var Woocommerce = WC.WC();

Woocommerce.get('products/categories', function(err, data, res){

console.log(res);
// $scope.categories = (JSON.parse(res)).product_categories;

// $scope.mainCategories = [];
// $scope.categories.forEach(function(element, index){
//   if(element.parent == 0)
//   $scope.mainCategories.push(element);
}) 

})

.controller('HomeCtrl',function(){

[janswist]

I have exact same problem as @gateway but no luck with this. I have website and parse-server on separate domains. Should it matter?

[fsultani]

res.header('Access-Control-Allow-Origin', '*'); worked perfectly for me. Strangely enough, my app continued working even after I removed it.

[jbeckton]

How was this project tested without them getting the same errors? Since the dashboard and parse api are likely always going to be on different hosts and it's all browser based cors will always be an issue.