CORS-Error: OpenSocial-Widget for Jazz-Dashboard fails to request Data from Server
Hi guys!
I'm creating an OpenSocial-Widget for the Jazz-Teamserver-Dashboard, which categorizes all Work-Items from different Project-Areas.
I was told to upload the widget to a GitHub-Repo and access it from the Jazz-Dashboard via URL.
When adding the widget, it is loaded, but fails to request the data from the server, because of the CORS-Policy of the Browser.
I've read a lot of posts about this issue, but the answers always implement direct access to the server, in order to fix the problem (e.g. change CORS settings in the server or storing the widget directly on the server).
Since I dont have direct access to the Jazz-Teamserver, those solutions don't help much.
Does anyone know, if theres another way to fix this, without having direct access to the server?
Is there anything I can do to make the request work?
Is there anything I can do to make the request work?
I really need your help, because I'm trying to fix this issue for weeks now. Nothing works.
Thanks in advance!
3 answers
From memory I believe you need to add the remote server to the whitelist on the Jazz server and then it will set up the necessary permissions. See:
I have read up on CORS in https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS what it does and why. You should as well.
It seems to be a safety measure that is supposed to protect users from being redirected to malicious sites. The task is shared in server and client/browser.
So unless you can deploy on your server, change the server settings to trust your other site or trick the client in ignoring CORS, your widget is likely not going to work.
> Does anyone know, if there's another way to fix this, without having direct access to the server?
I don't believe there is: modern browsers won't let a widget/javascript on a page from one server access a different server, it's a well-known historic attack vector which has been largely overcome with CORS. Jazz has whitelists for its proxy that allow a widget to talk through it to the remote server - but you need someone to approve/configure that on the server. As your widget might have access to any data that the logged-in user has, this constraint is quite understandable.