问题描述
We are configuring our Spartacus application with SSR in SAP Commerce Cloud. Also we used the IP Filter Set to secure our endpoints in SAP Commerce Cloud, (JS Applications, Backoffice and API).
We had experienced problems serving the request using SSR in our Spartacus application, after debugging the application we have confirmed the problem is in the whitelist of the API. When the whitelist is applied for a set of IP Filter set, spartacus is unable to access the API in SSR mode.
We had removed the restriction in API, allowing anyone to access the API to test our Spartacus SSR application and in this case the application is served using SSR.
问题分析
I checked your JS Storefront endpoint and it seems there is a CORS policy blocking the requests from JS-storefront endpoint to API endpoint. What you need to do is to configure it in that way it is not allowed. It can be configured either in properties (like here or in Backoffice in System -> Cors Filter -> CorsConfigurationProperty.
The message in console clearly states
“Access to XMLHttpRequest at ‘https://api.cetu9u54zw-cascade-d1-public.model-t.cc.commerce.ondemand.com/cascadeswebservices/v2/cascades-ca/cms/pages?lang=en&curr=USD’ from origin ‘https://jsapps.cetu9u54zw-cascade-d1-public.model-t.cc.commerce.ondemand.com’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: It does not have HTTP ok status.” so the issue is with the CORS Policy.
Can you add the property in Cloud Portal in hcs_common service so it is applied to all aspects as well as defining the jsapps URL and not ‘*’?
Also, I don’t know if you are doing that but please do not set up properties in hac directly. Changes made will only be done to a specific port the session is tied to and will be lost after pod restart.
So If I understand correctly we should split the issue into CSR/SSR and CORS/IP FIlter sets. When I last checked the issue was with CORS as I got the message in browser console related to CORS (the test was done on incognito mode). I checked on OOTB Spartacus and it sets storefront and jsapps URLs in the corsfilter and I believe it should work for either CSR or SSR. Right now I can see the site is working and API endpoint is public.
As for the IP Filter it will look a little different for SSR and CSR. In CSR all requests are done from customer IP so I would leave the API endpoint public. As for the SSR the site is rendered on server but I believe the requests are done via the API endpoint (and not somehow locally) so the environment IP must be whitelisted. All environment has the same IP address and you can check that by using some console tools or e.g. site like this: https://www.site24x7.com/find-ip-address-of-web-site.html. In your case the IP is 20.151.X.X. Still for SSR I would leave the API endpoint public. Also take note that IP filter sets added to the endpoint work as a blacklist when endpoint is public and whitelist when endpoint is private.
There is no other way than to make the API endpoint public (unless you know the IPs of all customers). In SSR some data is still accessed from client to API itself. Limiting only the SSR access to API endpoint will end up with the site fully rendered via the server so it won’t actually make much difference in comparison with default accelerator. Apart from that if for some reason SSR fails (e.g. due to a timeout) CSR would be used instead but if the API endpoint is private it would fail.
All cluster-internal IP’s are not static and will change at some point. So e.g. current jsapps pod has IP 10.244.1.48 but it will change at some point when the pod is restarted. I don’t believe there is any restrictions on communication between different services in the cluster. As I previously stated not all data is taken from SSR and as the user uses the site data is loaded via the API so the client IP (that makes the request to the API) should be whitelisted.