Hello Thomas, Please review your cors config, and double check whether you have the corsEnabled set to True. (See the attached image). Also you can use the tool at test-cors.org pointing to your own server to perform a quick test and send me the result. For example, testing ce-dev3 server: https://www.test-cors.org/#?client_method=GET&client_credentials=false&server_url=https%3A%2F%2Fce-dev3.gluu.org%2F.well-known%2Fopenid-configuration&server_enable=true&server_status=200&server_credentials=false&server_tabs=remote Best Regards -- Javier

Hi Javier. Thanks for the response. # corsEnabled For some reason I do not have the `corsEnabled` option in my settings (see linked image). Additionally, I checked the LDAP configuration under `gluu -> appliances -> <ID> -> configuration -> oxauth -> oxAuthConfDynamic` and the CORS related section looks like this ``` "corsConfigurationFilters": [ { "filterName": "CorsFilter", "corsAllowedOrigins": "*", "corsAllowedMethods": "GET,POST,HEAD,OPTIONS", "corsAllowedHeaders": "Origin,Authorization,Accept,X-Requested-With,Content-Type,Access-Control-Request-Method,Access-Control-Request-Headers,Access-Control-Allow-Origin", "corsExposedHeaders": "Origin,Accept,X-Requested-With,Content-Type,Access-Control-Request-Method,Access-Control-Request-Headers,Access-Control-Allow-Origin", "corsSupportCredentials": true, "corsLoggingEnabled": false, "corsPreflightMaxAge": 1800, "corsRequestDecorate": true } ], ``` Could this be a problem? # test-cors.org I ran the test on test-cors.org against our Gluu installation and got the following response ``` Sending GET request to https://example.com/.well-known/openid-configuration Fired XHR event: loadstart Fired XHR event: readystatechange Fired XHR event: readystatechange Fired XHR event: progress Fired XHR event: readystatechange Fired XHR event: load XHR status: 200 XHR status text: OK XHR exposed response headers: content-type: application/json access-control-allow-origin: https://www.test-cors.org Fired XHR event: loadend ``` # CORS headers On a different note, just for testing, I tried using the Gluu installation you used for test-cors.org, `https://ce-dev3.gluu.org/.well-known/openid-configuration`, for a request, and I see the same error in the browser console (Chrome) as I originally posted: ``` Access to XMLHttpRequest at 'https://ce-dev3.gluu.org/.well-known/openid-configuration' from origin 'http://example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. ``` It seems to me like Gluu is not setting `Access-Control-Allow-Origin: '*'` for the `/.well-known/openid-configuration` endpoint (possibly others as well?).

You can modify the Apache httpd config to suite your needs. Also note that for Angular applications, you should look at [AppAuth-JS](https://github.com/openid/AppAuth-JS) This library is more secure because it uses PKCE and the code flow.

Hello Michael. Thanks for your response. I managed to add the `Access-Control-Allow-Origin: "*"` header by adding ``` <LocationMatch "/.well-known/openid-configuration"> ProxyPass http://localhost:8081/oxauth/.well-known/openid-configuration Header set Access-Control-Allow-Origin "*" </LocationMatch> ``` to the file `/etc/apache2/sites-available/https_gluu.conf`. This alleviated the problem with the browser complaining about the CORS headers. However, I am now receiving a `403 Forbidden` response. This only happens when trying to retrieve the endpoint via XMLHttpRequest, if I open the endpoint directly in the browser, there is no problem. The output in the browser console is ``` GET https://example.com/.well-known/openid-configuration 403 (Forbidden) ``` And the only output relating to this that I've been able to find is in `/var/log/apache2/other_vhosts_access.log` which outputs the following ``` example.com:443 <IP> - - [01/Mar/2019:14:13:20 +0000] "GET /.well-known/openid-configuration HTTP/1.1" 403 528 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36" ``` Is this something you could happen to have some input on? Also, thanks for your input on the library for Angular, I'll consider whether this is something I should implement. Currently, I am working with the [angular-oauth2-oidc library](https://github.com/manfredsteyer/angular-oauth2-oidc).

For the record, which I forgot to mention earlier, I also tested with the [openid-implicit-client](https://github.com/GluuFederation/openid-implicit-client) provided by you guys with a simple HTML page: ``` <html> <head> <script src="https://cdn.rawgit.com/GluuFederation/openid-implicit-client/master/openidconnect.js"></script> </head> <body> <script> var providerInfo = OIDC.discover('https://example.com'); </script> </body> </html> ``` Two outputs in the browser console: ``` GET https://example.com/.well-known/openid-configuration 403 (Forbidden) ``` ``` Uncaught OidcException { message: "Unable to perform discovery: OidcException: Unable to retrieve JSON file at https://example.com/.well-known/openid-configuration : OidcException: fetchJSON - 403 Forbidden" name: "OidcException" } ``` Which is basically the same result as my homegrown test posted earlier.

Figured this out, it was an amalgamation of two unrelated things. First, it *seems* that Chrome blocks CORS requests from a local file and shows some output that I, personally, find confusing/misleading. The `403 Forbidden` error might be caused that block. Second, there was an implementation error in an Angular interceptor, which overwrote all headers for all requests, thus messing up the requests to Gluu. After fixing that, the Angular app was able to retrieve the discovery document. Unfortunately, these two issues just output very similar errors, which threw me off.

Thomas, Can you please post the final solution you have figured out? One of our devs is developing an application in Angular and is facing the exact issue that you faced. I saw in the apache site config that Access-Control-Allow-Origin header setting is disabled. Uncommenting it seems to be working, but I don't think it is a good idea to leave it on for every response issued by Apache. It'll be really helpful if you can share the solution that worked for you in prod environment.

Hi Sved. It's been a while so my memory on this is a bit fuzzy. I never figured out why Chrome was apparently blocking requests when sent from a local file and I don't remember if I tried other browsers. Regardless, I solved that part simply by adding my test file to a webserver and accessing it from there. I ended up **not** changing anything in the Gluu servers Apache configuration as the issue was not with Gluu. For the Angular application, simply make sure that your interceptor does not overwrite all the headers (like it did in my case) as described in the [Angular documentation](https://angular.io/guide/http#set-default-headers), otherwise you might be losing authentication and/or CORS headers. I hope this helps you resolve your issue.