Multiple Parent origin support

[karanakatle]

Hey, I have created a lex chatbot and deployed it using lex-web-ui.

Is there any way that instead of creating different deployment package, we can have multiple urls of the same domain name to the WebparentOrigin path in the cloudformation stack, so that chatbot should be available on all the environments.

I checked some of the previously asked question and tried giving wildcard domain name https://*.mydomainname.com in the cors policy of the S3 bucket, but it is not working. Chatbot becomes available only for the url added in parentOrigin of lex-web-ui-loader-config.json file.

Can you please help me in this?

[ojo-john]

Did you figure this out?

[karanakatle]

Nope..

[SharvariNagesh]

We are also facing the same problem. not able to have multiple origins. We tried having multiple origins separated by comma. but no luck. If any one has any suggestions, please post

[karanakatle]

I figure out a way for this and I guess you people might have tried that.

Creating a different alias of chatbot (for ex: dev and prod) and configuring that alias under the botAlias field of cloudformation stack and then creating a different cloudformation stack for different domains.

Means, for development parent URL botAlias should be dev and then for production parent URL botAlias should be prod.

In this case if we make any change in the Dev alias of chatbot, it won't affect prod alias unless we publish that version under prod alias.

[sk814]

I have a single s3 bucket used by different sites (.com and .de) using cloud front, not sure how to create 2 parent origins of the LexV2 Chatbot UI. If any one has any solution, please help.

[bobpskier]

@sk814 I think the best bet would be to deploy lexwebui twice. Configure one for each parent origin. Each lexwebui can support a single parent origin. Then in the "parent" html page hosted in the single s3 bucket, conditionally load the appropriate lexwebui based on the origin the client is operating against. Each lexwebui will have its own snippet of code. Both of these would be placed on the single parent page however only one would be used / selected based on origin the client is requesting.

[iamcrisb]

Any updates on this matter? Seems a bit dull to deploy 1 stack only for localhost

@bobpskier

[sv1033]

I figure out a way for this and I guess you people might have tried that.

Creating a different alias of chatbot (for ex: dev and prod) and configuring that alias under the botAlias field of cloudformation stack and then creating a different cloudformation stack for different domains.

Means, for development parent URL botAlias should be dev and then for production parent URL botAlias should be prod.

In this case if we make any change in the Dev alias of chatbot, it won't affect prod alias unless we publish that version under prod alias.

I need to integrate chatbot into more than 100 web sites. in this case do I need to create a more than 100 aliases and stacks? this may not be the ideal way of doing. is there a way how can I give multiple (100 website origins) in a WebAppParentOrigin section? Please answer. Thank you

[sv1033]

I need to integrate chatbot into more than 100 web sites. in this case do I need to create a more than 100 aliases and stacks? this may not be the ideal way of doing. is there a way how can I give multiple (100 website origins) in a WebAppParentOrigin section? Please answer. Thank you

[jawwadturabi]

facing same problem. Need support for multiple parent origin

[sv1033]

@jawwadturabi Looks like it is not possible to support multiple parent origins with existing Lex we ui. if we need this requirement to be implemented, there a way by forking the existing lex-web ui(https://github.com/aws-samples/aws-lex-web-ui) code and modify . one could fork this repo and create a custom code base that sets CORS to "*" in the relevant locations to allow any site to load the iframe . In addition one could comment out the javascript code checks to ensure correct parent origin and allow all internal api requests from the parent page to the iframe to be processed. one condition is, Ui which is about to be integrated to Lex should not have any authentication. if it will service anyone using the unauth role associated with the cognito identity pool then it can be implemented.