Hi, Nathan. Could you give some real-world example when something like that would be needed? Regards, Alex.

Alex, If the gluu server is running on identity.example.com and the client is running on client.example.com, when the client tries to explore the identity server via https://identity.example.com/.well-known/openid-configuration via an XmlHttpRequest the following error is seen: XMLHttpRequest cannot load https://identity.example.com/.well-known/openid-configuration. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://client.example.com' is therefore not allowed access. Does that help clarify? Thanks, Nathan

Yes, thanks for explanation. I believe it's about supporting [this standard](http://www.w3.org/TR/cors/). If I got you right, you are having issues while trying "implicit" (or "hybrid") flow of OpenID Connect; your client is fully implemented in javascript embedded into the page at http://client.example.com, and as it runs inside of some browser, same-origin policy applies, preventing it from accessing any data at https://identity.example.com using calls to javascript functions like XMLHttpRequest, is it correct?

I've verified that requests to all such should-be-universally-accessible urls like `/.well-known/openid-configuration`, `/.well-known/webfinger`, `/.well-known/uma-configuration` etc don't result in responses containing `Access-Control-Allow-Origin` (and similar) headers allowing to use the content of the response in a cross-domain manner, what indeed will create issues in case Nathan described. The solution to it seems to be Tomcat's standard [CORS Filter](https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter) which can be added to the `/opt/tomcat/conf/web.xml` configuration file. I gave it a try and successfully solicited a response with the header set to `*`. The correct settings for the filter is an open question, as well as whether or not to allow to send requests to endpoints like token or userinfo in a cross-domain manner. I'm handing off this ticket to our devs now. Thanks for bringing our attention to it.

From a OpendID core doc: > The UserInfo Endpoint SHOULD support the use of Cross Origin Resource Sharing (CORS) [CORS] and or other methods as appropriate to enable Java Script Clients to access the endpoint.

Alex, Yes, the situation is exactly as you have set forth. Glad to know I was on the right track. Thanks, Nathan

Created an issue on Github for it: [https://github.com/GluuFederation/oxAuth/issues/175](https://github.com/GluuFederation/oxAuth/issues/175) Will close this ticket now. Nathan you can either use this Tomcat's CORS filter as a workaround, or track the report's status waiting for its resolution. Thanks again for your cooperation

This is happening because of the [CORS](http://net-informations.com/js/err/xml.htm) (Cross Origin Resource Sharing) . For every HTTP request to a domain, the browser attaches any HTTP cookies associated with that domain. This is especially useful for authentication, and setting sessions. You are doing an XMLHttpRequest to a different domain than your page is on. So the browser is blocking it as it usually allows a request in the same origin for security reasons. You need to do something different when you want to do a cross-domain request. JSONP ( JSON with Padding ) is a method commonly used to bypass the cross-domain policies in web browsers. You're on domain example.com , and you want to make a request to domain example.net . To do so, you need to cross domain boundaries. JSONP is really a simple trick to overcome the XMLHttpRequest same domain policy. So, instead of using XMLHttpRequest we have to use < script > HTML tags, the ones you usually use to load JavaScript files , in order for JavaScript to get data from another domain. **Localhost** 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`