Enable CORS in Freescout API
-
Hello everybody,
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
-
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.
-
let's see...
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
First entry
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]Second entry
Request URL: https://ticket.paridata.net/api/conversations/6951 Request Method: OPTIONS Status Code: 200 Remote Address: 45.9.61.129: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.47So the preflight request is succesful however doesn't respond with any "Access-Control-Allow-XYZ" headers.
