On-premise Constellation App Static Content Service - CORS issue / Access-Control-Allow-Origin missing?
We have deployed Pega 24.1.2 in a private, on-premise environment using containerized deployment model.
To test Constellation UI in Sales Automation Insurance, we have also deployed a local Constellation App Static Content Service.
Pega Platform and CASCS share same toplevel domain (but different subdomains) and CASCS has a valid TLS certificate.
We have also deployed recent security fix.
When accessing Constellation UI, we see many CORS errors in Browser, similar to the following:
Access to fetch at 'https://pega-constellation.tld.com/c11n-appstatic/v102/app/<resource>.json' from origin 'https://pega-env.tld.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. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Is there a suggested way to configure CASCS to include a "Access-Control-Allow-Origin" response header?
Do you have other tips and suggestions why our setup fails?
Maybe @NigelJohnson or @RalphBogendoerfer can help?
Thank you!
***Edited by Moderator Marissa to update Support Case details***
Pegasystems Inc.
US
@MalteR In principal, there should not be a problem. We have many setups of different network architectures, with no issues. I am guessing that something small has gone wrong. Browsers incorrectly report many network errors as CORS errors. A couple of checks initially: 1. Is the pathway to appstatic good. Try https://pega-constellation.tld.com/c11n-appstatic/swagger.html in a new browser tab. Should work.
2. For your app web page, in the network requests, you should see the http OPTIONS call before the http GET call . OPTIONS call should be a 200 response. if that is good, and the get fails, that suggests that the requested content is missing. check the http response body for details
USU GmbH
DE
Hi @NigelJohnson,
thanks for the input. We did some adjustments and it seems now exactly as you described. We get a first OPTIONS call with a 200 followed by a 400 GET-call. In the response body we get something like this:
/usr/src/app/dist/customers/<ENV>/<APP>/locales/en-US/COMMON-LDM-ENTITY-CONTACT!ASSOCIATED!TYPEID.json has not been synced for this environment
With this we found an artivel that very much described the issue. https://docs.pega.com/bundle/platform/page/platform/user-experience/troubleshooting-localization.html
Sadly the remedy-steps do not help. As we have a fresh installation and are working with the defautl locale it should work. We did not set up additional things so adding more translations should also not be neccessary.
Are there any other things we are missing?
Pegasystems Inc.
US
@DanielGakstatterI have pinged the localisation team @[email protected] , who can assist with localisation specific questions.
USU GmbH
DE
@NigelJohnsonthanks for the support. I think we are now looking at two issues. One beeing the localisation, where we get above mentioned problems with sync. Here we tried reimporting with no further improvement.
The other problem seems to be the creation of the OAuth2. After some try and error we found the issue beeing a duplication of the clientid. Meaning the OAuth2 client registration we had for the application had the same clientid as one of the common-app. We are not sure how this has happened, but after some clean up this now seems to work. So the main issue now seems to be with localization. Can you give us a hint on what to do there?