About Content permissions
You can adjust permissions related to content at the community, container (category & group), and board level. Some permissions are set to Deny by default while others are set to Grant by default. At the container level and the board level, permission defaults and role permissions are inherited from the parent level. In those cases, the Inherit button is displayed in green to indicate that the permission was set to Grant at the parent level or red to indicate that the permission was set to Deny at the parent level. As an admin, you can manage these permissions. To manage content-related permission defaults at the community level: Note: To manage this permission at a lower level, go to the [Place] Permissions page and edit the permission defaults for that level. To manage this permission for a particular role, go to the [Place] Permissions page at the desired level of the community and edit the permissions of the individual roles. Go to the Roles and Permissions page for the community. Beside Community Permissions Defaults, select Edit. Review permissions in the following areas: Blogs Content Events Ideas Knowledge Bases Select Deny or Grant as required. Unless you have specified different permissions for certain roles or levels below the community level (a category, group, or board), these selections affect all members of the community. Content permissions While Forum permissions are granted by the Content permissions, Blogs, Event Boards, Ideas boards, and Knowledge Bases have distinct permission sections for content type-specific tasks. The Content permissions are provided for general content access and tasks and relate to all content types. Follow the links in the table below to learn more about the tasks granted by these permissions. Permission Default Related permissions in content type sections Read discussions and content Grant Blogs: Read posts and Read comments Ideas: Read ideas and comments Reply to discussions and content Grant Blogs: Comment on posts Events: Comment on events Ideas: Comment on ideas Knowledge Bases: Comment on articles Start discussions and new content Grant Blogs: Start new posts Events: Post new events Ideas: Post new ideas Knowledge Bases: Create, edit, publish, and manage articles Edit own posts Deny Blogs: Edit own published posts Events: Edit own events Ideas: Manage ideas and comments Knowledge Bases: Edit own published articles Edit any post Deny Blogs: Edit any published post Events: Edit all events Ideas: Manage ideas and comments Knowledge Bases: Edit any published article Move content Deny Blogs: Manage any posts and Manage own posts Delete own post Deny Blogs: Manage own posts Events: Delete own events Knowledge Bases: Delete own articles Delete any post Deny Blogs: Manage any posts Events: Delete all events Ideas: Manage ideas and comments Upload file attachments Deny Embed external content Grant Turn on link hyperlinking Grant Use simple HTML in posts Grant Use advanced HTML in posts Deny Use full HTML in posts Deny Make content read only Deny Post read-only content Deny Bypass moderation Deny Blogs: Bypass comment moderation Events: Bypass comment moderation Ideas: Bypass moderation Knowledge Bases: Bypass comment moderation Related topics: About Aurora Community site structure About Aurora Content TypesAbout Aurora community languages
Reaching all your customers and enabling them to connect with each other is important regardless of the languages they speak. That’s why we offer the ability to translate your Aurora communities and email notifications into many different languages. The following languages are currently supported: Chinese (Simplified) zh-CN Danish da-DK Dutch (Netherlands) nl-NL English (Great Britain) en-GB English (United States) en-US French fr-FR German de-DE Italian it-IT Japanese ja-JP Korean ko-KR Latvian lv-LV Polish pl-PL Portuguese (Brazil) pt-BR Portuguese (Portugal) pt-PT Romanian ro-RO Russian ru-RU Spanish (Spain) es-ES To make any of these languages available to your members, refer to Enable languages in your community. Note: More languages will be available in future releases. Community members can update their Community language in standard communities or their Email language in localized communities in their member profile preferences. To learn more about the Localized Communities feature in which you can create segments of the community aimed at users of a particular language, refer to About Localized Communities, Create and map a localized category, and Configure localized category settings.Aurora: Update community vanity URL
There are several actions you must take before we can change a vanity name on our end. The change is straightforward if your community is a non-SSO community, but if you use SSO there's a broader range of things to cover. As always, all changes should first be tested on stage if possible, and this is especially true if you're using SSO. Note: We highly recommend contacting our Professional Services team to complete this process, especially when using a custom SSO setup. Preparation Create a CNAME in your DNS. Point the CNAME at your internal community hostname (for example, communityid.community.com). Allow 48 hours to pass after steps 1 and 2 so the DNS can propagate the internet. Update the community URL Check your community settings and change any hard-coded URLs pointing to the old vanity name. A redirect largely covers this, but eliminating any non-needed page requests/redirects is always a recommended best practice. If you're using SSO and this change affects your SSO sign-in/sign-out/registration URLs, be sure to update them in Community Settings > System > Account and Privacy after the change is made on the Khoros side. IMPORTANT: if you're using SSO, make sure this domain change will not affect your authentication process. In most cases, SSO is domain-centric and works only for requests coming from the domain specified in the cookie, so if the domain is not updated in your SSO it could completely break authentication. For example, if your community URL was community.abc.com and your SSO was set for requests only from .abc.com, changing your vanity name to community.def.com would break authentication, since a cookie from one domain cannot be read by another. You need to update your SSO to ensure it's set to work with the new domain. If you're using a Salesforce integration, check with whomever handled that integration to ensure the change won't cause any unwanted problems. In some cases, that person might have to make changes to accommodate the change. Multiple vanity names are not officially supported, but if you plan to use more than one vanity name you MUST contact Khoros Support to have all of your domains added to a vanity domain allowlist. Any domain not in the allowlist redirects back to the active vanity name we have on record. After all of the above have been reviewed, tested, and you're ready to proceed, the remaining is completed by Khoros: Update the vanity name. Add any desired redirects (301) from the old vanity name to the new one so anyone who has bookmarks/favorites is redirected to the same page using the new domain. Add any other optional redirects you'd like in place. Depending on the number and/or type of redirects requested (for instance, more than a dozen), this may require an engagement through our Professional Services group. Restart the community during the next available maintenance window to apply changes. As noted, if you're using SSO we need to coordinate with you so that you can make any required SSO changes on your end at the same time we update the hostname on our end.Knowledge Base Article content widget configuration
The Knowledge Base Article template contains the Knowledge Base Article content widget that houses the body of an article. While you cannot delete this widget, you can modify some of its features to customize the community experience. Page item elements Date: Shows the date on which the article was published (September 3, 2024) or how long ago it was published (3 days ago) depending on your settings. Versions: A badge displays the version of the article. Helpfulness: Shows the “Was this article helpful?” section with sentiment emojis below the article. Guide navigation: In the left panel, shows the table of contents for the knowledge base guide where this article lives (see About KB Guides). Display contributors as None: No contributors are shown. Link: Select the View Contributors link to open contributors in another window. Detailed panel: The list of contributors shows below the article. Related topics: About Knowledge Bases About KB Guides Guides widget configurationAurora: Reverse proxy Best Practices
During pre-sales and launch, our customers often ask us about reverse proxy and vanity URLs. The question usually spawns from branding and search engine optimization (SEO) concerns. Some customers have corporate rules around aggregating all traffic for their domain. Branding, SEO, and corporate guidelines are all reasonable business considerations. In a branding-motivated scenario, a customer may want to use a subdirectory of the customer’s website, such as www.customer_name.com/community instead of our standard subdomain structure community.customer_name.com. With regard to SEO, you can find many articles that discuss how subdomains affect search engine optimization. The tricky part is determining whether the SEO benefit of a subdirectory structure is offset by latency potentially introduced with a reverse proxy. Khoros requires that any customer use of a reverse proxy be implemented in accordance with the appropriate implementation process specified by Khoros and set forth in the Statement of Work (SOW) that Khoros provides. The SOW sets out the process and important information that must be provided to support such implementation. Note: If you are using the Khoros Care with your Community, you also need to ensure that Care is able to communicate through the reverse proxy to Community in both stage and production. If you have IP address restrictions or other access restrictions for your reverse proxy, this might prevent integrations between Community and Care from operating correctly. What is a reverse proxy? In a reverse proxy implementation, community members do not access the community by directly connecting to Khoros servers. Instead, community members make requests to the proxy, which then makes requests to the community on the person's behalf. More generally speaking, any configuration that doesn’t include a CNAME to Community is a reverse proxy. What does Khoros recommend? As a general rule, Khoros strongly recommends against customer-controlled reverse proxy setups as these types of configuration introduce an unknown and uncontrolled layer between the end user (your customers) and our application. Occasionally, we have customers that do not discuss the concerns/goals described earlier with Khoros and add a reverse proxy in front of the community, managing the configuration and maintenance on their own. This practice often causes serious issues with community performance and stability that are difficult to debug. If you truly need a reverse proxy, we provide configuration options to create the most stable experience possible for you and your customers, and we have recommendations and best practices that we’ve learned over the years. Thoroughly discuss using a reverse proxy with Khoros, and work with Khoros Support to configure your request/response flow correctly. Using a reverse proxy—even with Khoros guidance and configuration—comes with costs that customers should understand before making the request. You may find that a reverse proxy's cost outweighs the benefits, or that Khoros has alternative solutions to consider about branding, security, and SEO that meet your needs without introducing a reverse proxy’s complexities. Let’s look at the complexities of customer-controlled reverse proxy implementations more closely: It's a black box to us. Customer-maintained proxies, using a technology of your choosing, are extremely difficult to debug and support without access to your infrastructure and specific proxy configurations. Coordinated debugging is required and can be very time-consuming. Working with Khoros to set up a reverse proxy integration properly pays off in the long run. Issues with a reverse proxy can confuse you and your customers. For example, if misconfiguration or performance issues with a reverse proxy arise, it looks like an issue with Khoros's application/infrastructure to end users. Similarly, Khoros has less information distinguishing users because all requests come from the proxy, which may be pooling connections, transforming requests, or otherwise acting differently than users’ browsers. It often takes some time to find the root cause of an issue. We’ve observed upwards of 2 times the response time for some customer-controlled reverse proxy setups, which can negatively impact SEO and dramatically reduce user retention. The reverse proxy flow has more steps than the standard Khoros response/request flow. More steps translates to extra server resources, a larger attackable surface area, extra latency for the user, and a performance bottleneck. A reverse proxy introduces an additional potential point of failure that is outside of Khoros’ control. If the proxy goes down, there's nothing Khoros can do to rectify the situation. It's entirely dependent on customer resources. Due to the lack of transparency, confusing indicators, and other complexities associated with a reverse proxy, the customer is responsible for verifying the source of any performance issues arising in a reverse proxy configuration. Khoros is not responsible for any performance issues related to or caused by a customer’s use of a reverse proxy. Therefore, it is critical that customers work with Khoros to implement a reverse proxy properly in order to minimize adverse effects. Okay, but what can really go wrong? Need some more concrete details? Here are a few issues we’ve encountered with customers who have attempted a reverse proxy implementation without Khoros guidance and proper community configuration: DNS issues: With incorrect DNS setup for the proxy or when pointing the proxy to Khoros servers incorrectly, the proxy can fail to connect. The failure might not happen at setup time but later when DNS records expire or when Khoros makes infrastructure changes. Examples we have seen include getting stuck in an infinite loop of self-requests, pointing at the wrong servers when we change IP addresses, getting turned away as invalid clients, or repeatedly being redirected to their own URL. The proxy fails to pass destination data from the original request: When this happens, we have no way of knowing the host and port that the end user (your customer) requested. We see only the host/port that the proxy requested. This incongruity can generate links and redirects with the wrong destination. In turn, if vanity hostname redirects are enabled, then the end user (your customer) is either kicked off the proxy or cannot access the community due to infinite redirects. Missing or incorrect client IP: If the reverse proxy doesn’t send the client IP, Khoros cannot get the end user IP. This makes all visitors appear to be from the same computer, which affects per-IP rate limiting and flood detection, IP bans, IP-based analytics in Community Analytics, IP-based geolocation, the Administrator IP-locking security feature, and the User IP address shown in reporting mechanisms. Response transformation: Actions such as injecting markup and JavaScript into the response has caused breakage for end users (your customers) that we could not reproduce or fix. What Khoros needs from you Your SOW order outlines the details of a reverse proxy integration. Here are a few things you can expect us to ask for: Emergency contact information: A person/team on call that we can call in the case of any integration issues, performance degradations, or outages SSL: We will use a secret header with a key to establish trust. Distributed proxy integration requires SSL to avoid the secret and key from being sniffed. These details are worked out during implementation. Proxy headers: We need to know which proxy headers you’re going to send. We require all of the following headers (these are the default, but they are customizable): X-Community-Proxy-Key: This passes the security key provided above and ensures the communication is really coming from your RP X-Community-Real-IP: Original user's IP address X-Forwarded-Host: Originally requested domain X-Forwarded-Proto: Originally requested protocol Requirements for a successful integration Make sure your proxy servers are robust, redundant, stable, and well-monitored. Connect from the proxy to the community via HTTPS for all requests. We also expect your proxy to require HTTPS for the end user. Make sure the 2 proxy headers above are populated correctly on every request. Point the proxy at the internal domain name provided by Khoros (for example, <your-company>.community.com). Do not configure using IP addresses. The community IP address may change at any time. It is recommended to preserve the Host header (for example, use "Incoming Host Header" for Forward Host Header in Akamai). It is acceptable not to preserve the Host header from the client. If you choose not to preserve it, you can pass the end-user request host using the X-Forwarded-Host header. The Host header should still reflect the internal domain provided by Khoros. If you decide not to preserve the Host header, let us know so we can configure it accordingly. proxy.allowForwardedHeader.host = true Do not alter the request or response (including all the headers and cookies) — be completely hands off to avoid regressions that are difficult to debug. If you must transform the request, let us know what you will be doing, and obey the W3C Guidelines for Web Content Transformation Proxies. We do NOT support CDN along with Reverse Proxy implementation, so alert us if you plan to use a reverse proxy so that we can take you out of our CDN. Khoros cannot update robots.txt in reverse proxy communities. You must work with your own IT team to update your robots.txt at the root level. Testing/Troubleshooting Both proxy headers, X-Community-Real-IP and X-Community-Proxy-Key, are mandatory to access the community in a reverse proxy setup across all instances. Consequently, any testing that bypasses the reverse proxy and directly targets our server must use a browser plugin (such as ModHeader for Chrome), to include both secret headers in the request. Still have questions? If you have questions about a reverse proxy implementation not answered in this article, or if you have implementation questions specific to your proxy configuration, discuss them with your Khoros Customer Success Manager.Set community to offline mode
If you are performing maintenance on your community, you may want to prevent activity from taking place as you resolve issues. With offline mode, you can present a notice to visitors so they know maintenance is underway and that they cannot participate until the community comes back online. When the community is in offline mode, members cannot: sign in read content create new posts or reply to any content like posts, mark posts as solutions, tag posts, or edit posts reply to messages in their inbox or create new private messages follow or manage existing follows update their member settings Members can still receive email notifications if content is posted by admins during the time the community is offline. When the community is in offline mode, admins are still able to: sign in to the community post content modify site settings update the theme use back-end functionality such as APIs Enable offline mode Open the Account menu and go to Settings > System. Below General, toggle on Enable community offline mode. Confirm this action by selecting Take Community Offline. Customize your maintenance page You can customize the title and message on your maintenance page so that your visitors know what to expect when they reach your community while it is offline. To customize the message: On Settings > System > General, below Enable community offline mode, select Edit beside Title and Description. In the Edit Offline Text window, edit the Title and Description as desired. Select Save.Aurora: Configure community guidelines
You can enable community guidelines for your community to ensure your members know what is expected of them in the community. These can be linked to an external URL or built within your Aurora community itself. You can designate your guidelines as required reading for registration or just provide a link on the registration window for new members. Depending on what you’re going for, building your guidelines within Aurora creates a seamless experience with consistent branding, while linking to an external URL enables you to use one central location where your document lives so you don’t have to update it in multiple places. For localized communities, you can provide guidelines in all your available community languages to ensure that all members of your community are aligned on expectations regardless of language. Provide link to guidelines on registration window Open the Account menu and select Settings. Go to System > Account > Registration. To add your guidelines to the registration window, turn on the Add community guidelines link to registration page toggle. (Optional) To require new members to select a checkbox indicating that they read and agree to the community guidelines, select Edit, and then select the Acceptance required checkbox. To designate whether you want to host the guidelines on your community or link to an existing page, select Edit, and then select Community or External. Set up guidelines on your community Whether your members reach your community guidelines from the registration window or elsewhere in your community, you can edit them from right within your community to ensure a seamless experience. After selecting Community, select Save. Select View/Edit Community Guidelines. On the Community Guidelines page that opens, select Edit Community Guidelines. Select a language from the drop-down menu. Select Continue. Enter your community guidelines. Repeat for your other community languages. Link to external community guidelines On the Edit Community Guidelines window, for all of your community languages, enter the URL to your community guidelines. Note: If you do not provide a URL for a particular language, members who select the community guidelines link while in that language are redirected to the community guidelines URL for your community’s default language. If the default language’s URL is also missing, members are redirected to the community-based guidelines page. Select Save.Aurora: Configure privacy policy
You can enable a privacy policy for your community to ensure your members know how your community collects, uses, and protects their personal data. Your privacy policy can be linked to an external URL or built within your Aurora community. You can designate your policy as required reading for registration or just provide a link on the registration window for new members. Depending on what you’re going for, building your privacy policy within Aurora creates a seamless experience with consistent branding, while linking to an external URL enables you to use one central location where your document lives so you don’t have to update it in multiple places. For localized communities, you can provide privacy policies in all your available community languages to ensure that all members of your community are aligned on security regardless of language. Provide link to privacy policy on registration window Open the Account menu and select Settings. Go to System > Account > Registration. To add your guidelines to the registration window, turn on the Add privacy policy link to registration page toggle. (Optional) To require new members to select a checkbox indicating that they read and agree to the privacy policy, select Edit, and then select the Acceptance required checkbox. To designate whether you want to host the guidelines on your community or link to an existing page, select Edit, and then select Community or External. Set up a privacy policy on your community Whether your members reach your privacy policy from the registration window or elsewhere in your community, you can edit them from right within your community to ensure a seamless experience. After selecting Community, select Save. Select View/Edit Privacy Policy. On the Privacy Policy page that opens, select Edit Privacy Policy. Select a language from the drop-down menu. Select Continue. Enter your privacy policy. Repeat for your other community languages. Link to an external privacy policy On the Edit Privacy Policy window, for all of your community languages, enter the URL to your privacy policy. Note: If you do not provide a URL for a particular language, members who select the privacy policy link while in that language are redirected to the privacy policy URL for your community’s default language. If the default language’s URL is also missing, members are redirected to the community-based privacy policy page. Select Save.Aurora: About Content Archive
Active communities, especially those of large enterprises, tend to have a lot of content. Over time, these communities can become cluttered with outdated, misleading, or obsolete content, making it more difficult for members to find the content they need. To keep content and conversations fresh and relevant, good content hygiene is important. Admins and moderators should regularly review site content and archive content that is no longer accurate, timely, or relevant. Aurora Communities include a Content Archive feature. When Content Archive is enabled, members with the appropriate permission can: Archive/unarchive knowledge base articles, blog posts, discussions, events, and ideas. Provide links to updated or related content in place of the archived content. Access all archived content from Manage Content dashboard . Note: You can archive only at the main thread. Individual replies or whole boards/categories cannot be archived. All user stats (likes, comments) achieved on archived content are retained. No notifications are sent to members when content is archived/unarchived. Admins and moderators can choose to send private messages to members as deemed necessary. Archival process Permissions Admins, moderators, or members with the Manage content archival permission can archive community content. Enable Content Archive feature To enable content archiving in your community, toggle on the Content archive option under Settings > Features > Moderation > Content Archive. Note: This feature is only set at the community level. Archiving content After the above mentioned roles or permission is granted and the Content Archive feature is enabled, members can see the Archive option from the Options menu on the content page. Select Archive to begin archiving the content. Below is an example from a discussion page. View archived content Admins and moderators or members with appropriate permissions can view all archived content from the Manage Content dashboard on the Archives tab. From here, they can unarchive, delete, or add a link to redirect users to related content.Aurora: Manage member account details
As your community grows, members may need help editing their usernames, email addresses, passwords, or SSO IDs, and admins may need to quickly adjust members’ assigned roles as requirements change across the community. With the Manage Members feature, admins and your company’s support team can edit these details within the admin area of Aurora. Note: To use this feature, your role must have the Manage roles and bans in admin & member profiles permission granted. Note: At this time, you cannot see a member's IP address until after they are banned. Refer to Review members banned from the community to learn how to view banned members' IP addresses. To edit existing member account details: Open the Account menu. Go to Settings > Users > Manage Users. In the Manage Members area, enter the Username or User ID (ID number or member profile URL) of an existing member. When you start typing a username, you can select the appropriate one from the list. On the Manage Member window, update the following as needed: Username Email address Note: If the existing email address has not been verified by the member, you can select the Mark email as verified checkbox to complete verification. If you change the email address here, it is automatically verified in the community. New password Roles (SSO members only) SSO ID Note: Be sure to update this field only when necessary, such as when SSO ID conflicts arise. Otherwise, the member may inadvertently create new accounts upon sign-in. Select Save.
