CORS Issue - deployed Lex web ui iframe

[karanakatle]

Hi Team,

We ran into a CORS issue for a deployed LEX WB UI lambda. Previously it was working fine on initial env. There was a requirement to move chatbot to other env.

We updated the cloudformation stack with webparentorigin as new env. There were some css stuffs and js files which we modified to have a chatbot working as per our expectations.

After cloudformation stack is complete we uploaded those modified css and js files back the S3 bucket. Provided the cloudfront invalidation and after clearing browser cache running into CORS issue.,

We checked CORS policy. A correct parent origin is mapped there. We checked lex-web-ui-loader-config.json. Parent origin and iframe both have a correct URLs.

Files modified were - custom-chatbot-style.css, index.html, lex-web-ui.min.js, lex-web-ui-loader.min.js.

CORS Error is : "Access to XMLHttpRequest at '/lex-web-ui-loader-config.json' from origin '' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource."

We added AllowHeaders=[*] in cors policy in S3 bucket but we have the same issue . In Origin request policy in Cloudfront URl, we have CORS-S3Origin and HTTP is getting redirected to HTTPS.

Still we are getting the same CORS error.

Is there any way we can solve it?

[bobpskier]

@karanakatle The following is how I would test and validate the config for CORS errors.

1) The S3 bucket hosting the lexwebui has a valid CORS policy. Something like:

[
    {
        "AllowedHeaders": [],
        "AllowedMethods": [
            "GET"
        ],
        "AllowedOrigins": [
            "https://yourvaliddomainparentdomain"
        ],
        "ExposeHeaders": []
    }
]

2) Make sure the lexwebui cloudfront distribution's behaviors are set correctly

3) Double check lexwebui config json file

4) Invalidate the lexwebui cloudfront distribution once again

5) Make sure no geographic restrictions are set on the lexwebui cloudfront distribution

6) Turn off all VPNs on the browser client side and test with this configuration

7) Clear all history again on the browser client

8) Test with an incognito / private browser window

9) Switch the cloud front distribution behavior to legacy CORS policy mode, invalidate distribution, test again. After test set back to the new CORS policy mode and test again.

10) Open a support ticket in the AWS account with AWS for invalid CORS processing in cloudfront and determine if AWS support can identify the problem.

[karanakatle]

@bobpskier thank you so much.. step 9 helped solving the issue.

I have one more query, we are looking for upgrading chatbot with voice interaction using Amazon Lex V2 and AWS Lambda... Is there any way to start a conversation with voice means if user clicks on microphone icon, chatbot should read the message before saying anything by user.

[bobpskier]

@karanakatle I'm curious, for number 9 did you set it back to the new CORS policies or leave it in legacy mode?

There is a parameter named, WebAppConfBotInitialSpeech, which can be used to indicate the initial speech to present when the mic button is clicked the first time. However, this is only enabled for users that have been authenticated and are using an auth role. The speech is translated to audio via the AWS polly service on demand from the client side and then presented to the user. In versions of lexwebui prior to the end of 2019, use of polly was available to anyone. It was not secured to authorized users. This was deemed an issue and at the end of 2019, use of polly by lexwebui was restricted to only authorized users.

[karanakatle]

Hi @bobpskier , we set it back to new CORS policies.

For WebAppConfBotInitialSpeech, our chatbot is going to be used by anonymous user, so in a code if I remove 'isLoggedin' condition for passing initial speech instruction. Will it have any effect in terms of security? I tried in my local version and it worked. For anonymous user also i was able to configure initial speech instruction.

1 more question. For lex v1, we have the custom slot types. Same slot types are used in multiple intents. We are adding 1 more intent using same custom slot types. Lambda code is same for all. Slot type values are not working for newer intent but the same values are working fine for the previous one. I have not added any value selection strategy for custom slot types for previous intent as well. Is there any way we can resolve it?