Aurora: Hide places and content from lists, menus, and search
In the community, you can hide any place (board or category) or posts related to a board (Forum, Blog, Knowledge Base, Event, and Ideas) from lists, menus, and search. Doing so hides the places and content from appearing in your community structure but still keeps them available to members via direct link to the content. To prevent search results from boards being directly accessible, you’d need to make the board private. Hide a place from appearing in lists, menus, and search Let’s take an example where you want to hide a category from appearing in the community place widgets, place picker menus, and search results. To hide a category: Open the Account menu and go to Settings > Community Structure. In Community Structure, click the category you want to hide. Go to Display Settings and toggle on Hide category in place widgets, place picker menus, and search. Similarly, to hide a board, you can go to the specific board and toggle on this setting: Hide content from appearing in a category, community content widgets, and search results Let’s take an example where you want to hide discussions in a specific forum from appearing in a category, community content widgets, and search results. To hide forum content: Open the Account menu and go to Settings > Community Structure. In Community Structure, click the forum you want to hide. Go to Display Settings and toggle on the Hide forum posts in content widgets and search. Similarly, you can hide Blog posts, Knowledge Base articles, individual events, and individual ideas of the respective boards from appearing in the category, community content widgets, and search results.Aurora: Permission descriptions
Each Khoros community permission enables users to perform specific actions. These permissions are assigned (either by default or manually) to different community roles. Permissions are grouped by feature area on the node where you’re assigning them: Accepted Solutions Analytics Badges Blogs Boards Case Portal Categories Community Content Escalations Events Following Groups Ideas Inbox Knowledge Bases Likes Media Member Management Member Profiles Mentions Moderation SEO Tags Widgets A description and a recommendation as to the type of member who should be granted this permission are displayed by each of the permissions so you know exactly what you’re granting and to whom. You can set permissions globally or at the node level (category or board) in the community structure. For each permission, you can keep the out-of-the-box default setting or explicitly Grant or Deny permissions as needed. About permission levels Manage community permission defaults About permission levels Permissions can be set to Inherit, Deny, Grant, or Assign. Inherit – Person has the permission defined in the node or node-level role above the current level. Therefore, this level does not display when you’re managing community permissions defaults but does display for the category, group, and board levels. You can hover your cursor over the Inherit button to see whether the inherited value is Deny or Grant (the button is also displayed as red for Deny and green for Grant). Deny – Person does not have the ability to take action described by the permission. Grant – Person has the ability to take action described by the permission. Assign – Person has the ability to take action described by the permission and has the ability to grant the permission to other members. Typically, this should be given only to Administrator roles. If you look at the Administrator role, you'll notice that all permissions are set to Assign since Admins can grant permissions to other users. As a general rule, only Admins should be able to Assign permissions to others. There are a few use cases where this could change, but typically speaking, Administrators should be the only ones that have the ability to manage permissions in the community. The different permission levels cascade down to any nodes below them, but certain permissions at higher nodes will override lower-node permissions: Assign Overrides any other permissions given at lower-level nodes Explicit Grant Overrides Default Deny, Explicit Deny, and Default Grant at lower-level nodes Explicit Deny Overrides Default Grant and Default Deny but not Explicit Grant at lower-level notes Default Grant Overrides Default Deny but not Explicit Deny at lower-level nodes Default Deny Does not override anything at lower-level nodes Note: If there are conflicts within roles, the explicit exists to override the default. So for example, if you set a permission to Assign at a particular level, all levels below that for that permission will be overridden even if they are set to Deny (including if you manually/explicitly set it to Deny). Note: It is a community management best practice to modify permissions at a role level rather than at a user level to ensure consistency across the community. Manage community permission defaults Setting community permission defaults enables you to grant the base permissions for all members of the community. To manage community permission defaults: Go to Settings > Roles and Permissions. In the Community Permission Defaults section, click Edit. (Optional) To jump to a specific permission to manage, enter it in the Find a permission field. Set Deny or Grant access for the settings in each area. Each permission entry displays a description and recommended deny/grant status, as shown in this example:Aurora: 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 Product Coaching Session: Spam Management Best Practise
Khoros Communities platform offers several settings and features that allow you to mitigate Spam in your community. Join our Spam Management Best Practice 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 Community site structure hierarchy and terminology
This quick reference guide lays out the hierarchy and meaning of some of the site structure terminology in Khoros Community Aurora. Hierarchy Glossary Term Definition Blog Board that houses blog posts Blog post Individual post on a Blog board Board General term for lower-level Place that holds content; encompasses Blog, Event board, Forum, Knowledge Base, and Ideas board Category Highest-level Container in your community; can contain Groups and Boards Comment A top-level response to a post on a Board Container General term for higher-level Place that houses Boards; encompasses Category and Group Content Collective term for posts (for example, “Our community contains a lot of content about our products.”) Content Type General term for the style of content that coincides with the Board types: Blogs, Events, Forums, Knowledge Bases, Ideas Discussion Individual post on a Forum Event board Board that houses events Event Individual post on an Event board Forum Board that houses discussions Group Higher-level Container that enables community members to engage around a common theme or purpose; can contain Boards of one content type Ideas board Board that houses ideas Idea Individual post on an Ideas board Knowledge base Board that houses knowledge base articles Knowledge base article Individual post in a knowledge base Place General term that encompasses Containers and Boards Post General term for an individual piece of content if type is irrelevant; encompasses blog post, event, forum discussion, knowledge base article, idea (for example, “If you want to make a post in our community, sign in first.”) Reply A response to a comment Related topics: About Community site structure Community Structure Best PracticesAurora: Replace community tags
Over time, tags associated with community content may become irrelevant, misspelled, or redundant. You can replace these tags to make more sense and make it easier to find relevant content. From the Tags tab in the Manage Content dashboard, Admins and members with the Manage Tags permission can replace the tags. After you replace a tag, the new tag is reflected in posts that used the previous tag. Key points to understand before replacing a tag: If the tag is associated with posts that are part of boards supporting preset-only tags and the replacement tag is part of the preset tags list, the tag is replaced in these posts. If the replacement tag is not part of the preset tags list, only admins can replace the tags in these posts by selecting Replace tag in the posts from the above boards option: When you replace the tag, the new tag is added to the preset tag list in the respective preset-only boards. Non-admin members (with the Manage Tags permission) cannot replace the tag and can only view a list of these preset-only boards: After replacing the tag in posts that are part of preset-only boards, admins can remove the old tag from the preset tag list of these boards by selecting the checkbox: A preset tag in a post can be replaced by a freeform tag if the board supports both preset and freeform tags. To replace a tag: Sign in to your community as an Admin or a member with Manage Tags permission. Open the Account menu and click Manage > Tags. In the row of the tag you want to replace, open the Options menu and click Replace. On the Replace Tag window, either enter the replacement tag name or select an existing tag. Click Replace. The new tag is reflected in the associated posts across the community.Aurora: Configure File Attachment settings for the community
You can configure settings that define how members can upload file attachments to different areas of the community. These settings apply to all content types. Note: These settings can also be adjusted at the board level. To configure the file attachment settings: Go to Admin Settings > Features > Content Features. Scroll down to File Attachments. Click Edit to configure the following settings: Maximum number of attachments per post – Enter a number or use the arrows to indicate the maximum number of attachments members of the community can upload. File extensions for attachments – Enter the file extensions to be accepted in the community. Separate file types with a comma. If you do not enter anything here, default file types (JPG, GIF, and PNG) will be used. Maximum attachment file size for upload (MB) – Enter a number or use the arrows to indicate the maximum file size members of the community can upload. Click Save.About the Brightcove video hosting service used with Aurora
Videos uploaded to a Khoros community are hosted by Brightcove. Note: Video upload is a paid feature. To learn whether Video Upload is included in your package or costs extra as well as request to have it enabled for your community, contact your Khoros Account Executive. To learn more about Brightcove video hosting capabilities and usage restrictions, refer to your Brightcove usage contract. This article answers some of the most common questions we get about the Brightcove integration. What video formats are supported? When you upload a video to Brightcove, Brightcove automatically transcodes it using the settings specified for your account and makes the videos available for playback through your player. We recommend that you upload videos to Brightcove in H.264. However, you can also use these commonly used file formats: Video Codecs: MPEG-1, MPEG-2, MPEG-4, VP6, VP5, H.264, H.263, WMV/WMA, and MJPEG. Audio Codecs: AAC, MP3, WMA, MPEG-1, MPEG-2, WAV, ADPCM. Learn more about supported formats on Brightcove's FAQ. What format are the videos served in? Videos are served in HTML5 format. Is there any limit to the number of videos that can be uploaded? With regard to the total number of videos that can be uploaded to your community, there is no limit. Is it possible to pre-moderate videos members upload? Yes, for members whom you trust will not upload inappropriate content, you can grant them the Bypass video moderation permission under Settings > Users > Roles and Permissions. By default, this permission is denied. Is there a concurrent views limit? No; however, there is a limit to the total number of streams/views per month. How many streams/views are allowed per month? Our standard package includes 120,000 streams per year. If you expect to regularly go over this threshold, contact your customer account manager to discuss options/costs for increasing this limit. What happens if I exceed more than 10K video views per month? If you exceed your monthly views limit, videos will still play for your members; however, your account will be charged for the additional views (similar to going over your data plan on your cell phone monthly plan). If you expect to regularly go over this threshold, contact your customer account manager to discuss options/costs for increasing this limit. What is the size limit for any single video? The largest file size (the maximum is 10,000,000 KB) that users can upload at any one time. As the Community Admin, you can set the maximum size under in your video options, described here. Learn more about Brightcove's video size limits. Is mobile supported? Yes, video playback is supported on mobile. Brightcove says I can use "up to 2 video encodes." What does that mean? With the Khoros/Brightcove integration, you can upload virtually any kind of video to Brightcove. The first thing Brightcove does is convert/encode that video to a suitable format for streaming. This means that that they might take your video and save multiple versions of it: one that’s small and highly compressed for viewing on phones one that’s larger but still compressed for viewing on desktop computers one that’s very large and only lightly compressed for HD viewing on high-bandwidth connections When visitors view your video, Brightcove determines which of these is optimal to stream to them based on what kind of device and connection the viewer has. In this example, there would be “3 encodes.” It’s about how many optimized copies of each video Brightcove stores so that each visitor gets the best video experience for the device they're using, not about the number of videos you can upload. Your Brightcove-Community integration supports up to 2 video encodes per video.Aurora: Best practices: roles and permissions
When you first launch a community, permissions and roles are fairly easy to manage because there are a limited number of roles, ranks, and members. As your community grows, you will need to add new ranks and roles to further segment your membership and reward the most active participants. Although you can set individual member permissions one at a time (not recommended), Khoros Communities are designed to help you manage permissions through a hierarchy of roles at the community, category, and board levels. The advantage to this approach, aside from the obvious reduction in the sheer number of moving parts, is a more predictable and manageable permissions structure. The cornerstone of this structure is a link the system creates between roles that have the same name, but that exist at different levels in the community. When you assign roles to members at the community level, they automatically inherit membership in roles that have the same name at the category and board levels. The settings for the new board-level role are stored with those of the higher-level role. Best practices for working with permissions and roles Keep it simple, especially when first launching your community. In the early days of the community, before your active members emerge, you can get by with just a few default roles (Administrator, Moderator, and Khoros or community defaults). At this stage, you want to encourage participation by making it easy for new members to sign in and start posting. You can add roles later as you need them. Set your community-level defaults to the lowest common denominator in terms of access. These defaults apply to all new community members at all levels of the community and are typically the most restrictive settings. As members gain experience in the community and advance up through the ranks, you can give them additional permissions through roles that explicitly grant access. You can always override these defaults with role-based settings at the category or board level. Create roles at the community level, and then create category- or board-level versions of the same roles if you need them. The purpose of a category- or board-level role is to override the community-level settings for a specific category or board. Members who have the community-level role also get the permission settings from the lower-level roles. The names of the roles at all three levels must be exactly the same—including capitalization and spacing—for the connection between roles to work. For example, “Vip” and “VIP” are not the same. The lower-level settings apply only when members are at that level. For example, a category-level permission applies only to members in that category. Elsewhere in the community, community-level permissions are in effect. Always assign roles at the community level rather than at lower levels. This enables you to manage roles and permissions from a single location rather than having to go to each category, for example, and listing the members who have a role assigned to them. Members get the access allowed by the community-wide settings as well as the category-level or board-level override settings for specific categories or boards. The category- or board-level roles typically give members access to areas or features that are off-limits to the rest of the community. Always use roles to assign permissions. The system is designed to track membership in a role, not individual permission settings. As a result, you can easily determine which roles a member has or which members are assigned to the same role. While you cannot assign permissions to individual members, you can look up which roles & permissions are assigned to a particular member (see Look up a member's roles and permissions.) Observe these general tips: Configure permissions and roles to the Principle of Least Privilege. (Apply only the minimum required permissions for a role.) Change permissions within roles only where the default, inherited permission doesn't suffice. For each role, fully document the function of each role, its included permissions, and its purpose and location (for example, if it exists at child levels of community). Provide these details in the role description. Use an informative and consistent naming convention when creating roles. Clear and concise role names make roles much easier to scan and manage and enable new admins to intuit the meaning/purpose of a role.
