• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Confige webserver for access to .NET backend running at different port (current problem: CORS fails in OPTIONS preflight)?

Willy K.

New Pleskian
Hello at all,
I'm running Plesk Obsidian 18.0.35 on a Debian 10 system. The plan is to run a .NET Core application at some port, f.ex. http://my-domain.tld:1234 and https://my-domain.tld:4321, which is accessed by an React front-end application using fetch(). Since there is no official support for .NET on Linux I followed the official documentation at Microsoft and that worked without any problems, time to test:
  1. Built the React app on my local computer and copied the files to the htdocs on a subdomain (f.ex. test.my-domain.tld)
  2. Build the .NET backend app at the server (dotnet public -c Release ...), "cd" into the "publish" directory and run the app manually (./myapp &)
    AddCors() etc. is in place (allowing everything - just for the moment, of course), and "appsettings.json" contains, among others:
    "Urls": "http://my-domain.tld:1234;https://my-domain.tld:4321"
    "https_port": 4321,
That works well as long as long as I access my site via http://test.my-domain.tld and fetch() is sent to http://test.my-domain.tld:1234. I can also access my site via https://test.my-domain.tld and contents are loaded so far, but fetch() https://test.my-domain.tld:4321 fails in the CORS OPTIONS pre-flight with SEC_ERROR_INADEQUOTE_KEY_USAGE (FireFox) ERR_CERT_AUTHORITY_INVALID (Edge).

I think that is something that needs to or can be configured at the server, but I don't know how and where. Do you have any suggestions? Thanks in advance.
Willi K.

P.S: The domain uses a valid Let's Crypt certificate that was added via the Plesk UI..
 
Last edited:
I found a solution by myself - for everyone who's interested:
My mistake was to the clients accesses test.my-domain:xxxxl, regardless if http or https, directly in meaning of that the webserver was bypassed entirely :rolleyes:. The only thing I need to do is to configure a reverse proxy in the additional NGINX directeves which redirects requests to /my-access-point-name to my .NET backend running at http://localhost:xxxx (no https required). The clients - of course - need to communicate via this new /my-access-point-name

Code:
location /my-access-point-name {
    proxy_pass http://127.0.0.1:xxxx/route/;
}

Maybe not the perfect solution at all, but it works
 
Back
Top