3

I'm trying to implement user authentication login and currently trying out to configure JSS connected mode to work with https (secure connection).

Following https://jss.sitecore.com/docs/techniques/authentication/sitecore-auth document.

I got my integrated site configured with https with local cert.

Now I'm try to use JSS start:connected to connect my app in secure channel, but I'm getting 500 error page. But I can see data is correctly returned from the Layout service in the network tab.

Following error appears on the browser console

Access to XMLHttpRequest at
'https://hostname/sitecore/api/layout/render/jss?item=%2F&sc_lang=en&sc_apikey=%7BA%7D'
from origin 'http://localhost:3000' has been blocked by CORS policy:
The value of the 'Access-Control-Allow-Credentials' header in the
response is 'true, true' which must be 'true' when the request's
credentials mode is 'include'. The credentials mode of requests
initiated by the XMLHttpRequest is controlled by the withCredentials
attribute.

Any help would be highly appreciate

4

It looks like the Access-Control-Allow-Credentials value was added twice, hence the value is shown as "true, true".

Try removing it first then add again.

<remove name="Access-Control-Allow-Credentials" />
<add name="Access-Control-Allow-Credentials" value="true" />
  • Surely that was the reason. It seems to be adding from twice. So I just add remove entry and its started to work with data coming from secure path from layoutService – scFootsteps May 30 at 11:40
  • Could you expand on this? I am facing a similar issue where I need to allow credentials for SSC, but adding that header to Web.config results in the true, true header for the JSS Layout service. The above code didn't have any affect in my case. – Mark Oct 4 at 18:49
  • 1
    @Mark, in my case, I added the extra line <remove name="Access-Control-Allow-Credentials" /> to remove all previously added header for "Access-Control-Allow-Credentials". The next line then adds it back again to ensure that it is only added once. If that is not working for you, then it just means that there are some other later location that adds the header again. – Fredric Foo Oct 11 at 4:54
  • I suspect you're right. We're running SXA 1.9 and JSS 12 together, and I have a hunch it has to do with that. We eventually solved it with a small custom preprocessor that adds the header dynamically based on a URL whitelist and it seems to be working well for us. – Mark Oct 12 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.