Setting up a proxy is complicated.

[miguelvaara]

If the proxy server is on a different server than the widget itself, CORS errors occasionally occur in different browsers, and the suggestion does not reach its destination. For example, on the production server:

Cookie “” has been rejected as third-party. update.min.js OR (the error message below)

Likely, either changes need to be made on the proxy server, possibly related to CORS settings, or a more user-friendly configuration option needs to be built to facilitate the setup of the proxy server. Currently it must be directly edited for the Webpack in the components.js file located at the root of the widget (setting the proxy to the server that is on the same machine as the widget):

module.exports = JSON.parse('[{"url":"https://finto.fi/plugins/suggestions/gh_prx.php"}]');

---

_Access to XMLHttpRequest at 'https://dev.finto.fi/plugins/suggestions/gh_prx.php?payload=%7B%22title%22%3A%22aaaaaaaaaaa%22%2C%22body%22%3A%22%5Cn**K%C3%A4sitteen%20tyyppi**%5Cn%5CnCONCEPT%5Cn%5Cn**Ehdotettu%20termi%20suomeksi**%5Cn%5Cnaaaaaaaaaaa%5Cn%5Cn**Ehdotettu%20termi%20ruotsiksi**%5Cn%5Cn%5Cn%5Cn**Ehdotettu%20termi%20englanniksi**%5Cn%5Cn%5Cn%5Cn**Tarkoitusta%20t%C3%A4sment%C3%A4v%C3%A4%20selite**%5Cn%5Cn%5Cn%5Cn**Perustelut%20ehdotukselle**%5Cn%5Cnaaaaaaaaaaa%5Cn%5Cn**Ehdotettu%20yl%C3%A4k%C3%A4site%20YSOssa%20(LT)**%5Cn%5Cn%5Cn%5Cn**Ehdotetut%20temaattiset%20ryhm%C3%A4t**%5Cn%5Cn%5Cn%5Cn**Vaihtoehtoiset%20termit**%5Cn%5Cn%5Cn%5Cn**Alak%C3%A4sitteet%20(RT)**%5Cn%5Cn%5Cn%5Cn**Assosiatiiviset%20(RT)**%5Cn%5Cn%5Cn%5Cn**Vastaava%20k%C3%A4site%20muussa%20sanastossa**%5Cn%5Cn%5Cn%5Cn**Aineisto%20jonka%20kuvailussa%20k%C3%A4sitett%C3%A4%20tarvitaan%20(esim.%20nimeke%20tai%20URL)**%5Cn%5Cnaaaaaaaaaaaaa%5Cn%5Cn**Ehdottajan%20organisaatio**%5Cn%5Cn%5Cn%22%2C%22state%22%3A%22open%22%2C%22labels%22%3A%5B%22uusi%22%5D%7D' from origin 'https://finto.fi' has been blocked by CORS policy: Request header field access-control-allow-origin is not allowed by Access-Control-Allow-Headers in preflight response.
xhr.js:187

POST https://dev.finto.fi/plugins/suggestions/gh_prx.php?payload=%7B%22title%22%3A%22aaaaaaaaaaa%22%2C%22body%22%3A%22%5Cn**K%C3%A4sitteen%20tyyppi**%5Cn%5CnCONCEPT%5Cn%5Cn**Ehdotettu%20termi%20suomeksi**%5Cn%5Cnaaaaaaaaaaa%5Cn%5Cn**Ehdotettu%20termi%20ruotsiksi**%5Cn%5Cn%5Cn%5Cn**Ehdotettu%20termi%20englanniksi**%5Cn%5Cn%5Cn%5Cn**Tarkoitusta%20t%C3%A4sment%C3%A4v%C3%A4%20selite**%5Cn%5Cn%5Cn%5Cn**Perustelut%20ehdotukselle**%5Cn%5Cnaaaaaaaaaaa%5Cn%5Cn**Ehdotettu%20yl%C3%A4k%C3%A4site%20YSOssa%20(LT)**%5Cn%5Cn%5Cn%5Cn**Ehdotetut%20temaattiset%20ryhm%C3%A4t**%5Cn%5Cn%5Cn%5Cn**Vaihtoehtoiset%20termit**%5Cn%5Cn%5Cn%5Cn**Alak%C3%A4sitteet%20(RT)**%5Cn%5Cn%5Cn%5Cn**Assosiatiiviset%20(RT)**%5Cn%5Cn%5Cn%5Cn**Vastaava%20k%C3%A4site%20muussa%20sanastossa**%5Cn%5Cn%5Cn%5Cn**Aineisto%20jonka%20kuvailussa%20k%C3%A4sitett%C3%A4%20tarvitaan%20(esim.%20nimeke%20tai%20URL)**%5Cn%5Cnaaaaaaaaaaaaa%5Cn%5Cn**Ehdottajan%20organisaatio**%5Cn%5Cn%5Cn%22%2C%22state%22%3A%22open%22%2C%22labels%22%3A%5B%22uusi%22%5D%7D net::ERR_FAILED_

[miguelvaara]

Suggestion for fixing the problem is as follows:

A bit of additional help for resolving the issue. The "chain" for submitting the suggestion to GitHub works as follows at a high level:

1. From the browser, a "package" of information in a format suitable for a GitHub issue is sent to the specified proxy server.
2. The proxy server receives the package and sends it to the GitHub API, along with providing authentication and authorization information to GitHub.
3. GitHub receives the "package," and if it was successful, it sends a response, information to the proxy that the receiving was successful, and also the URL of the created issue.
4. Once the proxy has received the information about successful sending to GitHub, it sends a response back to the client's browser, indicating that the sending was successful, along with the GitHub issue's address, which is used to inform the client of the success and provide them with the GitHub link. In case of an error, information about the failure is sent.

Before resolving the issue, the above "chain" needs to be refined to show the specific request and response headers used at each step.

In order to fix the actual issue, @osma provided the following hint:
The error message Request header field access-control-allow-origin is not allowed by Access-Control-Allow-Headers in preflight response would imply that in the POST request, for some reason, the header 'access-control-allow-origin' is included. This seems to be incorrect, as it is not a request header but rather a response header.

[osma]

My hunch is that the header issue prevents CORS from working. So if the proxy server is on a different host than where the widget is published, the cross-origin request will fail. But if the proxy is on the same server, CORS is not needed, thus the header issue is irrelevant and everything works.