Safari browser generating new sessionID on 2nd utterance to bot.

[SandeepPasula898]

Hello, We are facing an issue when we run this application in safari browser. The sessionID is changed when we send second request to bot in same session. My first sessionId looks something like this - 'lex-web-ui-466f' but second sessionId looks normal - 'us-east-1:ef9545c2-40ac-49c7-8c03-98fd6933f302'. This problems only happens in safari browser (MAC machine). It works fine in other browsers like chrome/edge/firefox.

[bobpskier]

@SandeepPasula898 Based on your description, I suspect some setting or extension in Safari. If you use the safari browser debugger and look under Storage tab you should see something similar to

aws.cognito.identity-id.us-east-1:[id]	us-east-1:[some id]

Cognito generates and stores its id in local storage for the parent page. If Safari does not preserve this in local storage then I suspect it would reload a new session on the next request. If it is storing the id, does it change on new requests?

Is there a URL that is shareable for testing?

[itsdishant]

@bobpskier I am working on a project with @SandeepPasula898 on such a thing. I can confirm that Safari is not preventing storing session-id in local storage; I can see that. I can also confirm the pattern of session in local storage is the same as you mentioned above.

Unfortunately, there is no URL we can provide you because the chatbot is hosted inside an account that requires credentials.

The issue has been fixed but the chatbot is loading but not visible after fixing the session ID issue. Out of 10 tests, only 5 or fewer times the chatbot button is visible (issue occurs only in Mac Safari). This new issue has halted us to go live. Out chatbot is hosted at Sharepoint as a web part.

Please help us out asap. Any help will be thankfully appreciated.

[bobpskier]

@itsdishant @SandeepPasula898 The Safari browser console should display a message with respect to why the load of the chatbot is failing. Its probably a timeout but I'm curious what other errors are present? Could this potentially be due to a CORS issue? Are you using a lexv2 or lexv1 bot? What parameters are being configured for the cloudformation deploy of lex-web-ui that are different from the defaults? A site that I maintain is loaded by Safari 10 out of 10 times correctly using Safari version 15.4 (17613.1.17.1.13). https:://lander.tioth.com. Can you test against this page and let me know if the browser fails to load the lexwebui?

Does the sharepoint origin change in anyway between requests? If the origin was a problem then I suspect other browsers would hit the same failures so probably not this.

Safari use was problematic in the past when lex-web-ui templates configured CloudFront to use legacy cache settings. Is the CloudFront distribution behavior using Legacy policies or using the newer cache policy CachingOptimized / CORS-S3Origin?