Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross-origin resource sharing setting isn't applied #258

Closed
Janneman96 opened this issue Jan 24, 2018 · 8 comments

Comments

@Janneman96
Copy link

commented Jan 24, 2018

I'm running SenseNet 7.0.0, running it with ASP.NET 5.2.3 and I'm trying to run an api call from an Angular (Typescript) application. The Angular application runs on localhost:4200 and the ASP.NET application runs on localhost:55064. I followed this tutorial for installing Sensenet and used this tutorial for installing WebPages.

When I run an api call, I get this error:

The 'Access-Control-Allow-Origin' header has a value 'http://localhost:55064' that is not equal to the supplied origin. Origin 'http://localhost:4200' is therefore not allowed access.

In the Content Explorer, I navigated to Root/System/Settings/Portal.settings. In the settings, I added the next code to the bottom of the file:

,
AllowedOriginDomains: [ "http://localhost:4200", "http://localhost:55064/" ]

I've also tried it with [ "*" ] and [ "localhost" ] instead of the two localhosts. Here is a screenshot of the portal.properties file. I didn't forget to click the save button after changing the value. I expected this would fix the issue, but it didn't. Even though it should not involve a restart, I tried restarting the asp.net project and the server. That didn't resolve the problem either. I tried these solution because the sensenet wiki and the sensenet docs stated that the url's of external applications should be added to the AllowedOriginDomains to whitelist them.

How do I fix the error above, which I get when I try to reach the API with an external program?


I don't think the Angular call is the issue here, but just in case:

Import statement:

import {HttpClient} from '@angular/common/http';

HttpClient injection:

constructor(private http: HttpClient) {
}

Angular api call:

testApiCall() {
  this.http.post(
    Configuration.ServerWithApiUrl + '/Odata.svc/(\'Root\')/Login?metadata=no',
    '"username" : "admin", "password" : "admin"')
    .subscribe(data => this.callResult = data);
}

Here is the error one more time:

The 'Access-Control-Allow-Origin' header has a value 'http://localhost:55064' that is not equal to the supplied origin. Origin 'http://localhost:4200' is therefore not allowed access.

This is an ajax call that is runned from the asp.net project on localhost:55064. That shows the succes message. It also shows the succes message when I run it from a stand-alone html file. It shows the error when I run it from a stand alone file too. In the error instead of "localhost:4200", it shows "null".

function testLoginCall() {
    $.ajax({
        url: "/Odata.svc/('Root')/Login?metadata=no",
        dataType: "json",
        type: 'POST',
        data: JSON.stringify({
            'username': "admin",
            'password': "admin"
        }),
        success: function (d) {
            console.log('You are logged in!');
        }
    });
}
@tusmester

This comment has been minimized.

Copy link
Member

commented Jan 24, 2018

We should check and finalize the behavior around domains and ports. IMHO he two-localhost environment should work, but maybe https is also a requirement.

If there is a bug: fix it. If there is a limitation: document it.

@Janneman96

This comment has been minimized.

Copy link
Author

commented Jan 24, 2018

I'm still a student, so I'll have to look into how I can host the Angular application on https instead of http. I'm going to pick that up now.

If there is a bug: fix it. If there is a limitation: document it.

Is this a message aimed for me? I don't understand what your intent is. Do you want me to fix/document the sensenet bug/limitation? I'm not a native English speaker, so that might be the issue.

@tusmester

This comment has been minimized.

Copy link
Member

commented Jan 24, 2018

Nonono, this was just a comment to my colleagues, to whoever will start working on this issue, I hope you did not get offended :). Thanks for reporting this, we appreciate it and I hope we can sort it out.
🍰 ☮️

@Janneman96

This comment has been minimized.

Copy link
Author

commented Jan 24, 2018

I'm very happy you are picking this up so quickly!

Some background information why I'm using Sensenet:
I'm trying to decide between Kentico and Sensenet. My company has very much knowledge of Kentico and almost no knowledge of Sensenet. Sensenet has the advantage that it generates the API and that it is set up pretty quickly if you know the right steps. I need a cms like that, that doesn't take much time to create CRUD functionality, because I'm working on full-stack components that our developers can implement in new projects. The decision between the two is timeboxed for monday. If Sensenet ends up being a useful addition to this project, you might have yourself a mid-sized company in the Netherlands that will be using Sensenet.

@tusmester

This comment has been minimized.

Copy link
Member

commented Jan 24, 2018

Just FYI: we have a sample TODO application for Angular that uses the new JWT login through our client sdk. The latest version of this sample app is not yet published to the main branch, but you can access it here:

https://github.com/SenseNet/sn-angular2-redux-todo-app/tree/feature/sn-client-update

I recommend that you check this out, because this is actually necessary for an Angular app to work. It takes care of managing the whole login process, sending headers etc. The old Login api will not work in a modern one-page app environment.

@Janneman96

This comment has been minimized.

Copy link
Author

commented Jan 25, 2018

The api calls work just fine in Angular when I run the Angular project on the same server as the ASP.NET project. More details: https://stackoverflow.com/a/48446268/4686096

@purplemana

This comment has been minimized.

Copy link

commented Jul 24, 2018

This issue is especially painful while trying to run a create-react-app bootstrapped application against a sensenet core backend.

@herflis herflis added the bug label Jun 12, 2019

@herflis herflis added this to the Sprint 188 milestone Jul 2, 2019

@herflis herflis modified the milestones: Sprint 188, Sprint 189 Jul 10, 2019

@tusmester tusmester self-assigned this Jul 24, 2019

@herflis herflis modified the milestones: Sprint 189, Sprint 190 Jul 24, 2019

@herflis herflis modified the milestones: Sprint 190, Sprint 191 Aug 7, 2019

@tusmester

This comment has been minimized.

Copy link
Member

commented Aug 7, 2019

We've release a version that supports defining allowed domains with a port number. Please try it and verify that it solves the issue.

https://github.com/SenseNet/sensenet/releases/tag/v7.6.3

Please note that from now on the allowed domain needs to contain the port if it is different from the default port for that scheme. This means that simply defining localhost may not be enough, you may need to add the port too.

@tusmester tusmester closed this Aug 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.