Resolved Issue with cross-origin, Plesk is locking

[PeopleInside]

Hi, I have recently moved to Plesk and I have an issue:

There I have an Help Desk Ticket platform: HelpDesk HelpDesk Siti Web Marco Borla where on the right bottom should be showed a live chat widget that is blocked (Browser Developer Console) with the error: Multi-origin request blocked (cross-origin)

I have not this issue only at this helpdesk address but same issue also on my other website Marco Borla | .:. Marco Borla .:. IT where the same live chat widget is blocked.

How can I resolve?
Thank you.

I have already visited the following guide: https://support.plesk.com/hc/en-us/...s-origin-resource-sharing-in-Plesk-for-Linux- but is not helping, not resolving the issue.

 

[Monty]

It looks like you did not correctly implement the solution in the KB you referenced. Your website does not provide any "Access-Control-Allow-Origin" headers. You can see that when you analyse the headers that are sent from your website. Your current headers are:

HTTP/2.0 200 OK
server: nginx
date: Tue, 23 Nov 2021 15:46:04 GMT
content-type: text/html; charset=UTF-8
content-length: 7671
cache-control: max-age=0, must-revalidate, private
pragma: no-cache
expires: Tue, 23 Nov 2021 15:46:04 GMT
vary: Accept-Encoding
content-encoding: gzip
strict-transport-security: max-age=15768000; includeSubDomains
x-powered-by: PHP/7.4.26, PleskLin
X-Firefox-Spdy: h2

=> No Access-Control-Allow-Origin headers exist, so your chat widget is blocked by the browser as it comes from a different origin.

Please re-read the KB article https://support.plesk.com/hc/en-us/...s-origin-resource-sharing-in-Plesk-for-Linux- and make sure that the headers are correctly set.

 

[PeopleInside]

Sorry but this reply sound not helpful.
The strings in the guide are not working, Plesk is not accepting when I paste into Apache & Nginx header add section.
I tried to put there: Access-Control-Allow-Origin: * but this also never work.

Is not useful have again the guide I already linked and is not resolving.
Once I save settings I need restart something or should be applied and work?

 

[Monty]

Well, NOW the header exists, but it did not exist before. So apparently you changed something.
If the header is present but CORS still doesn't work then you'll have to debug your code. A good starting point is this: How to Debug Any CORS Error

 

[PeopleInside]

Thanks I'm reading but I don't understand much.
Before I was in a server that has not the cross-origin directive.
Maybe Plesk insert is as default.
If I cannot remove in some configuration file, that may also be overriten always by Plesk, I don't see how I can resolve.

The chat widget that I need load is the chat widget that is visible there: Marco Borla | .:. PeOPLeInSiDE .:. IT
The chat URL is Fill in the form to start a chat « Siti Web Marco Borla - Live Support

Now I insert the rule to allow every origin on Plesk but is not working, I think because somewhere on Plesk, a default setting set the same origin.
If anyone can help me, I have no idea on how to resolve this issue, my chat widget are loaded only on peopleinside.it and not to other websites.
I have more than one websites so I need allow all of these.

 

[PeopleInside]

Look, I set Access-Control-Allow-Origin: "*"
but I get the error Allow Origin doesn't much *
I don't understand how to resolve.
The same rule are added also on helpdesk subdomain.



Results:

 

[PeopleInside]

If I look from Edge the browser console say:
'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed.

So it's Plesk that is causing this issue, seems.
I inserted the code:
Access-Control-Allow-Origin: "*"
is not multiple values as browser read so it's Plesk that give multiple value.

 

[PeopleInside]

Well, NOW the header exists, but it did not exist before. So apparently you changed something.
If the header is present but CORS still doesn't work then you'll have to debug your code. A good starting point is this: How to Debug Any CORS Error

I think the issue is that Plesk seems is inserting two times the directive that I insert just one in Domains > example.com > Apache & nginx Settings.
If I read the guide How to set up CORS (cross-origin resource sharing) in Plesk for Linux? I can see this:

Warning: Only one header Access-Control-Allow-Origin can be added. CORS will not work if the header is defined both in nginx and Apache, or twice for Apache or nginx respectively.

This seems to be what is happening to me but is Plesk that put the directive two times.
If I remove the only one directive " Access-Control-Allow-Origin: "*" " I get the error No 'Access-Control-Allow-Origin' header is present on the requested resource.
Any idea on how to solve? I need stop some service at Plesk services like the Reverse Proxy Server (nginx)? But what hapen if I stop it?
My website will be down?

 

[PeopleInside]

I cannot see my live chat until this issue will not get fixed. I tried to go on..

Oh I have resolved.

For resolve the issue I need stop the Reverse Proxy Server (nginx) service and keep it off, stopped. Than need to go on the domain and set headers to the default settings removing my custom settings. Is very strange how I get this issue... with default Plesk settings and how I resolved. Seems I need to keep stopped a process that was active when Plesk was installed Reverse Proxy Server (nginx), has not been activated by me.

 

[AntonM@Parallels]

It is hard to say about exact reason, as there is no full configuration/Plesk settings shared, although CORS configuration and article #115001338265 in particular was tested on many installations, so it should technically work.

Plesk does not add any CORS headers by default, although some software itself may have it hard coded.

Proxy Nginx server is enabled by default as a proxy server on all Plesk installations as it help to improve overall server performance, when disabled it is only Apache and in such configuration your server also should be working just fine.

 

[PeopleInside]

It is hard to say about exact reason, as there is no full configuration/Plesk settings shared, although CORS configuration and article #115001338265 in particular was tested on many installations, so it should technically work.

Plesk does not add any CORS headers by default, although some software itself may have it hard coded.

Proxy Nginx server is enabled by default as a proxy server on all Plesk installations as it help to improve overall server performance, when disabled it is only Apache and in such configuration your server also should be working just fine.

Thank you for your reply, I really appreciate that.

I just know the default Plesk settings never let me see my widget chat working because I get miss cross origin directive so I tried to add and start to see the double directive issue.

Thank you, happy now is resolved on my side, also if I don't know well why.

 

[PeopleInside]

Hi, I still have this issue. Is true I have resolved but disabling HTTP2.
Any idea on how can I resolve in HTTP2 the issue that create cross script origin double?
As soon I activate HTTP2 the issue of this topic return to be present.

 

[PeopleInside]

Solution: Forwarded to devs - HTTP2 and CORS issues

From Plesk developer:

The problem is not related to HTTP 2 and not a bug in Plesk.

Live Helper Chat (LHC) inserts CORS headers for dynamic content by itself and for static content it relies on Apache .htaccess config. By default Plesk uses nginx in reverse proxy mode with nginx serving static content as directed by X-Accel-Redirect header set by Apache (see Apache with nginx). Unfortunately, in this mode nginx loses CORS headers for static content, which were set in .htaccess and emitted by Apache. Therefore, the client receives no CORS headers for static content and that's why LHC doesn't work in cross-origin setting with Plesk by default.

Setting Access-Control-Allow-Origin for all content in nginx config as per https://support.plesk.com/hc/en-us/...s-origin-resource-sharing-in-Plesk-for-Linux- doesn't help either, because then CORS headers are duplicated for dynamic content (set both by LHC and by nginx).

You can fix this problem by reproducing LHC .htaccess configuration in nginx config only for static content served by nginx. To do this, use the following additional nginx directives (replacing "example.org" with your domain name):

location ~* ^/internal-nginx-static-location/(.+\.(gif|jpe?g?|png|bmp|swf|css|js|svg|otf|eot|ttf|woff|woff2|swf|mp3|ogg|wasm|wav|pdf|ico|txt))$ {
    alias /var/www/vhosts/example.org/httpdocs/$1;
    internal;
    add_header Access-Control-Allow-Origin '*';
    add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS, PUT, DELETE';
    add_header Access-Control-Allow-Headers 'Origin, X-Requested-With, Content-Type, Accept, API-Key, Authorization, X-Test';
}

You may also limit the scope of these directives by setting appropriate regular expression. For example, if your LHC is installed in the "lhc_web" subdirectory, you can use "location ~* ^/internal-nginx-static-location/(lhc_web/.+\.(gif|jpe?g?|png|bmp|swf|css|js|svg|otf|eot|ttf|woff|woff2|swf|mp3|ogg|wasm|wav|pdf|ico|txt))$" above. Then CORS headers will be added to LHC static content only.

Thank you very much to this forum, to Plesk team for helping me to sort out this last issue for me!

 

[jefryarch]

error: Multi-origin request blocked (cross-origin)

The Same Origin Policy (SOP) is the policy browsers implement to prevent vulnerabilities via Cross Site Scripting (XSS). In other words, the browser would not allow any site to make a request to any other site. It would prevent different origins from interacting with each other through such requests, like AJAX. This policy exists because it is too easy to inject a link to a javascript file that is on a different domain. This is a security risk - you really only want code that comes from the site you are on to execute and not just any code that is out there.

The Cross Origin Resource Sharing (CORS) is one of the few techniques for relaxing the SOP. Because SOP is "on" by default, setting CORS at the server-side will allow a request to be sent to the server via an XMLHttpRequest even if the request was sent from a different domain. This becomes useful if your server was intended to serve requests from other domains (e.g. if you are providing an API).

JSON with Padding is just a way to circumvent same-origin policy, when CORS is not an option. This is risky and a bad practice. Avoid using this.

If you want to bypass that restriction when fetching the contents with fetch API or XMLHttpRequest in javascript, you can use a proxy server so that it sets the header Access-Control-Allow-Origin to *.

If you need to enable CORS on the server in case of localhost, you need to have the following on request header.

Access-Control-Allow-Origin: http://localhost:9999