Solved Enable CORS in Freescout API
I have bought the Freescout API Addon in order to sync conversations to my ninoxdb database at https://app.ninox.com. It allows me to start a request from inside the browser to Freescout API. However I obviously run into cross origin resource sharing problems. So I would like you guys to allow CORS for the Freescout API. I need a way to specify which hosts are allowed to share resources with and which headers. The headers in question are Authorization and/or X-Freescout-API-Key.
Hi and welcome!
Not exactly sure how the communication is, but you may want to set CSP config for the app for a start https://docs.cloudron.io/apps/#custom-csp
Headers as such should be forwarded normally by the reverse proxy, so if you hit this issue we have to debug this somehow with your setup to fully understand the issue.
If Freescout as such does not support CORS then this is an upstream issue with Freescout (or in this case the API addon) Usually we have seen that they are quick to fix issues once reported
While CORS can be enabled in the reverse proxy, the correct place to do this is in the app itself. The app alone knows if it's API has been designed and tested for Cross Origin use cases. Enabling it without understanding the app will is a security issue. So, I guess this comes down to asking Freescout to add these headers in their responses.
@paridata If you report this, can you please link the github issue or support request here? I am happy to chime in.
Here‘s the link to the github issue: https://github.com/freescout-helpdesk/freescout/issues/897
Hi, Freescout has already implemented the feature. It is installable through the Freescout module store.
After doing the upgrade and specifying the allowed host in the app and clearing the app's cache, I'm still not getting the desired behaviour. Is there some sort of caching happening on the cloudron side? I've tested on my side in an anonymous browser window. As far as I know the ninoxdb app does not intercept/cache the responses from cross origin requests.
Can you guys say if the app is doing what it should?
I am not aware of any such caching on Cloudron side. This is a bit hard to test without that plugin.
There is a new freescout version coming as well, was released just today. Maybe there were some changes needed as well. I am just building the new app package.
@paridata Can you test with the latest Freescout package we released?
doing the equivalent to
curl -X GET -G "https://ticket.paridata.net/api/conversations/6951" -H "X-FreeScout-API-Key: [api key removed]"
Browser dev tools/Network tab output
Request URL: https://ticket.paridata.net/api/conversations/6951 Referrer Policy: strict-origin-when-cross-origin Provisional headers are shown Accept: */* Referer: https://app.ninox.com/ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.67 Safari/537.36 Edg/87.0.664.47 X-FreeScout-API-Key: [api key removed]
Request URL: https://ticket.paridata.net/api/conversations/6951 Request Method: OPTIONS Status Code: 200 Remote Address: 220.127.116.11:443 Referrer Policy: strict-origin-when-cross-origin allow: GET,HEAD cache-control: max-age=0, must-revalidate, no-cache, no-store, private content-length: 0 content-type: text/html; charset=UTF-8 date: Fri, 04 Dec 2020 08:26:51 GMT pragma: no-cache referrer-policy: no-referrer-when-downgrade server: nginx strict-transport-security: max-age=15768000 x-content-type-options: nosniff x-download-options: noopen x-permitted-cross-domain-policies: none x-xss-protection: 1; mode=block :authority: ticket.paridata.net :method: OPTIONS :path: /api/conversations/6951 :scheme: https accept: */* accept-encoding: gzip, deflate, br accept-language: de,de-DE;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6 access-control-request-headers: x-freescout-api-key access-control-request-method: GET origin: https://app.ninox.com referer: https://app.ninox.com/ sec-fetch-dest: empty sec-fetch-mode: cors sec-fetch-site: cross-site user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.67 Safari/537.36 Edg/87.0.664.47
So the preflight request is succesful however doesn't respond with any "Access-Control-Allow-XYZ" headers.
Since many other apps use CORS normally, I don't think our reverse proxy gets into the way here. Maybe this is still something the upstream addon needs to investigate?
Right, I think this is Freescout not sending the correct CORS headers. The reverse proxy in Cloudron just passes everything through.
Is this issue now solved since the upstream issue was resolved again?
This issue has been fixed.
This is great news!