Aurora Product Coaching Session: Spam Management Best Practices
Khoros Communities platform offers several settings and features that allow you to mitigate Spam in your community. Join our Spam Management Best Practices coaching session to identify, filter and deal with spam effectively. Our coaching session will guide you through the practical tips and techniques to help combat spam and help maintain the hygiene of your community. Topics covered in the coaching session Overview of Aurora spam settings and functionality Manage Content dashboard related to spam management and its features Using roles and ranks to configure permissions to check spammers Content Filters Best practice tips Notes - Admin permissions are required to conduct the call. 👉Click here to Sign Up Related Resources Enable Spam Management Community Spam Management Review Posts Captured as Spam Khoros Academy: Communities Moderation Essentials Khoros Academy Instructor Led Training: Spam Management for Communities AuroraAurora: Assign roles to members in bulk via CSV file import
To assign or remove a large number of roles for members at one time, you can use bulk import via a CSV file. Your CSV file needs to include the following for each member: “ADD” or “REMOVE” indicator Username or email address The roles you want added or removed To bulk assign or remove roles: Go to the Settings > Roles and Permissions page. In the Community Roles area, click Assign Roles in Bulk. On the Assign Roles in Bulk window, browse for the CSV file on your local machine. In the Charset drop-down menu, select the character encoding of the CSV file you’re importing. The default for Microsoft Windows operating systems is windows-1252 for most locales saved through Microsoft Excel. Click Start Assignment. Larger sets of member assignments may take longer to be imported. When the import is complete, you receive an email indicating whether it was a success or if there were any errors that need to be corrected. Related topics: Create a role Add members to rolesAurora: Manage image and video settings and permissions
Manage image settings Permissions Members must have the Add images to post permission to upload images. Members with this permission can add images to community content. To enable this permission for specific roles: Go to Settings > Users > Roles and permissions. Open the options menu (3 dots menu) for the role you want to grant this permission to. Select Media. Select the type of permission for the Add images to post permission as needed. To enable this permission for all members in the community: Go to Settings > Users > Roles and permissions. Scroll up the page and Edit for Community Permission Defaults. Select Media. Select the type of permission for the Add images to post permission as needed. Note: We recommend that you grant this permission only to trusted members to combat spam. Configure video settings To enable and configure image-related settings for your community: Go to Settings > Content Features. Select Media. Turn on Image uploads to enable members to add images to their content. In the Additional image settings section, select Edit to set the maximum file size (in MB) for uploaded images. Select Save. To override the setting to upload images lower-level categories or boards: Navigate to the desired place in the place picker. Scroll to the Media section under Content Features. Turn on or off Image uploads as needed. Supported file formats For Ranks, Aurora supports these image formats: .png and .svg For all other images, Aurora supports these image formats: .png, .jpg, .jpeg, .gif Manage video settings Note: Videos uploaded to a Khoros community are hosted by Brightcove. Learn more about the Brightcove video hosting service. Permissions Members must have the following permission to upload videos. Members with this permission can add videos to community content and messages. To enable this permission for specific roles: Go to Settings > Users > Roles and permissions. Open the options menu (3 dots menu) for the role you want to grant this permission to. Select Media. Select the type of permission for the Add videos permission as needed. To enable this permission for all members in the community: Go to Settings > Users > Roles and permissions. Scroll up the page and Edit for Community Permission Defaults. Select Media. Select the type of permission for the Add videos permission as needed. Note: We recommend that you grant this permission only to trusted members to combat spam. Configure video settings To enable and configure video-related settings for your community: Go to Settings > Content Features. Select Media. Turn on Video uploads to enable members to add images to their content. Select Edit to set the maximum file size (in MB) for uploaded videos. Turn on or off the ability to embed externally-hosted video content. Select Save. To override the setting to upload videos at lower-level categories or boards: Navigate to the desired place in the place picker. Scroll to the Media section under Content Features. Turn Video uploads and Embed external videos on or off as needed. Bypass media moderation You can grant trusted members or roles with trusted members the permission to bypass moderation for the media content they publish in the community. Learn more on how to grant this permission.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.About Aurora Community site structure
One of the most important aspects of setting up your community is choosing which content types to include and how to organize them. Communities are structured hierarchically—they’re broken down into Places, which are divided into Containers and Boards. Containers consist of Categories and Groups, while Boards consist of Forums, Knowledge Bases, Blogs, Ideas, and Events. Typically, Categories and Groups are made up of Boards—these boards are the areas where community members can post and reply or comment on what they read. Categories can also be broken down into other Categories as necessary. Containers Containers are higher-level Places like Categories and Groups. Categories are areas that can house several types of Boards that are broken out into different types of content. Groups are similar to Categories, but they are designed for specific groups of Community members who want to collaborate on a particular subject or project. Create a Category Create a Group Create a Category Go to the Community Structure page. Select Add (plus icon) at the level of the community where you want to add the category. On the window, enter a Name and ID. The ID displays in the URL for the category. Note: The ID must be a single word made of only letters, numbers, dashes, and underscores with no spaces. It cannot be changed later. Optionally, enter a Description and add an Avatar for the category. Select Create. For more information, see About Categories. Boards Create a Forum Create a Knowledge Base Create a Blog Create an Ideas board Create an Event board Boards are Places that are subsets of Containers. The types of boards available in your community are Forums, Knowledge Bases, Blogs, Ideas, and Events. Boards enable members to post content, write comments, and reply to other members’ comments. The process for creating a board is similar for all content types. To create a board: Go to the Community Structure page. Select Add (plus icon) at the level of the community where you want to add the board. On the window, enter a Name and ID. The ID displays in the URL for the board. Note: The ID must be a single word made of only letters, numbers, dashes, and underscores with no spaces. It cannot be changed later. Optionally, enter a Description and add an Avatar for the board. In the Tags area, specify the types of tags to use, add preset tags, and/or indicate whether you want to require tags for the board. Select Create. Related topics Community Structure Best Practices Community site structure hierarchy and terminology Manage Containers or Boards Container and Board permissionsAurora: 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.Aurora: Enable read-only mode for community places
From time to time, you may need to lock down areas of your community for standard maintenance or updates. Or, you may want to temporarily restrict people from creating new content in specific categories, boards, or the entire community. By putting community places in read-only mode, you can enable members access to still view community content but restrict them on making any changes to this content. You can enable read-only mode at the community, category, or board level to restrict members from posting new content or editing existing content. Read-only mode does not apply to admins and moderators; they can perform their respective actions as normal. Read-only mode is commonly used for these reasons: Community: Standard site maintenance where site activity could interfere with the site updates or when a community is under a security threat. Category: For categories dedicated to broadcasting information and does not require members to post any content. It can also be used to temporarily or permanently make a category read-only. Board: For boards that are dedicated to broadcasting information and does not require members to post any content. It can also be used to temporarily or permanently make a board read-only In addition to the above scenarios, admins and moderators can enable read-only mode on a case-by-case basis based on their specific needs. Note: We recommend this setting only for specific cases as it highly impacts the member site engagement. You should also let your members know why a community place has been temporarily placed in read-only mode. What to expect in read-only mode In read-only mode, members can: View, like, or report inappropriate content Tag their own content (When set at places below community level) Send private messages to other members In read-only mode, members cannot: Create new content Edit or delete existing content Add comments or replies to content Tag others’ content Move content to another location (When set at community level) Send private messages to other members Note: Members are blocked from performing the above actions even if they have appropriate permissions. Enable read-only mode at the community level Open the Account menu and go to Settings > Content Features. In the General section, toggle on the Read-only mode option. Configure read-only mode at the category, group, or board level When read-only mode is enabled at community level, it is inherited at the category, group, and board levels. You can override the setting at lower levels as needed. Let’s look at an example where read-only mode is turned off at the community level and you want to enable it in a specific category. To enable read-only mode for a specific category: Open the Account menu and go to Settings > Community Structure. In the Community Structure, click the category where you want to enable read-only mode. Below Content Features, toggle on the Read-only mode option. Similarly, you can configure read-only mode at group and board levels.Aurora: Redirect user to related content
When you archive content, you can provide a permanent redirect link to related content within the community or an external page. Members who attempt to access archived content (via permalink) see a notification indicating that the content has been archived and redirected to relevant information. Though this is optional, it is best practice to provide a related link to relevant content while archiving. For instance, if a Google search result suggests a piece of content that was archived in your community and members select that link, they are automatically redirected to the related content in your community. As the redirection occurs for several members, the Google crawlers understand that the old link is replaced and boost up the new link's ranking instead of the old link. If you didn’t do this when you archived the article, you can opt to add it later from the Archives page. Add a URL to related content Sign in to the community Select Archives on the Manage Content dashboard. Select the Options (...) menu and select Add Link to Related Content. A window to enter the URL opens. Enter a link to the relevant content in your community. Select Add. The entered link is added. After an article is archived: Members who are not admins or moderators are redirected to the page that was added as related content. If no redirect URL is provided, they land on an empty page as shown below. Community admins and moderators land on the original page and see a notification that the page was archived. A link to the related article is provided. Furthermore, you can edit the added link from the archived page by opening the Settings menu and selecting Edit Link to Related Content. Add a URL to an external page You can also redirect members to external pages outside the community. To achieve this, toggle on External URLs under Settings > Features > Moderation > Content Archive.Aurora: Unarchive Content
When content is unarchived, it returns to its original location in the community before it was archived. The position of the original board list is also retained. The article's publish/last updated date is retained. Also, you cannot unarchive content whose board has been deleted. Assume that topic B was archived from the board list with topics A, B, C, D, and E. If topic B is later unarchived, it returns to its original position, and the board list again shows topics A, B, C, D, and E and not A, C, D, E, and B. To unarchive content: Go to the Manage Content page. Select Archives. Select the Options menu (...) in the row of the content you want to unarchive. Select Unarchive. The original location of the archived post is selected by default: You can also choose to unarchive the content to another location in the community. 5. Select Unarchive. You receive confirmation that the post is unarchived to the selected location. As shown below, you can also unarchive the content from the content page by opening the Settings menu and selecting Unarchive.Aurora: Delete Archived content
To delete content: Go to the Manage Content page. Select Archives. Open the Options menu in the row of the content you want to unarchive. Select Delete. A window to confirm the delete action opens. 5. Select Delete. The archived content is permanently deleted from the community and cannot be retrieved.
