Hallo community,
we set up a "on-prem" Appian instance (actually on AWS) to develop and test custom plugins (especially components).
General setup is OK, also instance is successfully registered as dev instance.
Since it is just an internally used dev instance, we decided to use something like
appian.###.internal.###.com to access Appian (left it on port 8080 for the sake of simplicity)
Static/dynamic URLs follow the same principle:
Additionally we set the parameter conf.suite.DISABLE_STRICT_DOMAIN_SECURITY=true
conf.suite.DISABLE_STRICT_DOMAIN_SECURITY=true
Unfortunately we have difficulties with the configuration of static and dynamic content URLs, so self developed components are not working properly.
Reading through documentation (https://docs.appian.com/suite/help/22.4/Post-Install_Configurations.html) and other posts (https://community.appian.com/discussions/f/administration/13390/static-and-dynamic-content-url) it is clearly stated to use 3 unique TLD.
Is there any workaround for not using 3 top-level-domains to get components working? (Appian is not using 3 TLDs on their cloud instances to differentiate static, dynamic content AFAIK)
As I mentioned, it is "just" a dev environment used by a handful of devs.
Thank you,
Dan
Discussion posts and replies are publicly visible
You might also try adding this parameter to the custom.properties file...conf.suite.DISABLE_SIBLING_DOMAIN_SECURITY=true
As referenced in the public documentation in the blue box titled "Why do I need to register separate domains for these URLs?", browsers implement security controls between web content hosted in different domains. We recommend hosting third party content (either uploaded by users or enabled by component plugins) in separate top-level domains because it provides the most assurance that code introduced via one of these mechanisms cannot access unintended content in Appian, other systems in the same domain, or other third-party content.
For organizations that are unable to register independent top-level domains, we have an undocumented configuration (the one referenced in this comment) option that enables third party content to be hosted in subdomains. We recommend anyone considering use of this option familiarize themselves with the details of "same origin policy" and related topics such as "cross-site scripting attacks", and discuss the tradeoffs of allowing third party content in this manner with their security team.