New Features
- Support for reCAPTCHA v2
- FreeMarker upgrade
- New permission to embed content hosted by third-parties
- You Found It. We Fixed It.
With the 17.7 release, Lithium now supports reCAPTCHA v2, which is designed to establish whether a computer user is human or a bot.
Up to now, Lithium used reCAPTCHA v1. Recently, Google ended support for reCAPTCHA v1, in favor of reCAPTCHA v2. reCAPTCHA v2 provides additional security for users entering sensitive information and dramatically simplifies the CAPTCHA process. With reCAPTCHA v2, users must only check a single box ("I am not a robot"), rather than enter an image challenge passphrase.
With the 17.7 release, Lithium will be upgrading all customers using reCAPTCHA v1 to reCAPTCHA v2 and creating new Site and Secret Keys. Community customers not using reCAPTCHA are unaffected by this upgrade.
Important: Since Google is no longer supporting reCAPTCHA v1, Lithium will stop supporting v1 with this release.
Learn more about reCAPTCHA v2 and review these common FAQs.
Enabling reCAPTCHA v2
New customers and existing customers who want to turn on reCAPTCHA after the 17.7 release can do so themselves and no longer need to open a Support ticket.
Note: The upgrade to reCAPTCHA v2 changes the requirement for completing a verification challenge from once per session to once per post submission.
Enabling reCAPTCHA v2 involves two tasks:
To run automated tests with reCAPTCHA v2, you need to create both a Site Key and Secret Key:
- Open a browser and go to Google's registration site.
- Enter the URL for the site you want to register and generate keys.
- Select the reCAPTCHA V2 option.
- Accept the reCAPTCHA Terms of Service and click Register.
- Copy down or copy to your clipboard both the Site Key and Secret Key.
Use these keys when you enable reCAPTCHA in Community Admin in the next procedure.
Enable reCAPTCHA in Community Admin
You can enable reCAPTCHA for various verification scenarios, either globally or for specific boards/pages. When noted, specific user permissions are also required if the verification process is to be triggered.
To enable and configure reCAPTCHA v2 for your community:
- Go to Community Admin > System > Authentication.
- If needed, click Choose to select the specific page/board where you want to apply the reCAPTCHA settings or set global settings on the top-level Community page.
- Enable the scenarios where you want users to be presented with the reCAPTCHA verification challenge:
- Require verification when registering: presents challenge when users register for the community.
- Require verification when sending private messages: presents challenge when users try to send private messages to other users. This option also requires that the Post private messages without verification permission be set to Deny for the desired roles in your community.
- Require verification for users to post messages: presents challenge when users try to post new Forum messages. This option also requires that the Post messages without verification permission be set to Deny for the desired roles in your community.
- Require verification for anonymous users to comment on blogs: presents challenge when users try to post comments on blogs.
- Enter the Site and Secret keys you got in the previous procedure.
- Click Done.
Here's an example of how the reCAPTCHA appears on the user registration page:
We've upgraded our FreeMarkder version 2.3.26.
New permission to embed content hosted by third parties
We have added a new permission: Use HTML which can embed third-party content. This permission can be used to restrict a user's ability to embed content hosted by third parties within a message body. Typically, this is done with HTML that makes user's browser request the content outside the community, for example: <img src="http://thirdpartysite.example/some-image.png>.
This permission does not restrict users from embedding content hosted by third parties within signatures.
When set to Deny, the permission adds an additional layer of restriction to the HTML tags and attributes allowed by the following permissions:
- Use simple HTML in posts and signatures
- Allow user to use advanced HTML in posts and signatures
- Use full HTML in posts and signatures permissions
See Allowed HTML tags in the Community text editor for more information about each permission.
If the user has Use HTML which can embed third-party content set to Grant, the user can post according to the permissions above -- no additional restrictions are applied. If the user has Use HTML which can embed third-party content set to Deny, the user cannot use embed content hosted by third parties within the message body.
Note: While this permission is granted to all users by default, we recommend you discuss this permission with your security team to determine which users, if any, should be allowed to embed third-party content within a message body.
This is the set of HTML attributes denied to a user whenUse HTML which can embed third-party content is set to Deny:
- img:src|srcset
- script:src
- source:src
- embed:src
- body:background
- frame:src
- iframe:src
- audio:src
- video:src|poster
- track:src
- object:archive
- style:src
Note: We do not have a configuration or Community Admin to whitelist trusted hosts for this permission.
- We have fixed the browser issue where people using Internet Explorer 11 could not upload certain file types.
- When reordering the order of badges in the Admin > Users > Badges screen, the new order was not saved/retained when you clicked Save. This issue is now fixed.
- Previously, you were able to create duplicate usernames using the users/add API (user.sso_id), even if the SSO integration didn't allow it or if the username was hosted on our side via the select a screen name page. We have fixed this issue and now the API returns a message that there is a naming conflict.
- Previously, when you used a LiQL query with the online_status constraint, the results always returned all users (online and offline), regardless of the status specified. This filtering issue has been fixed.
- The Time Zone drop-down menu under user preferences is now localized based on the user's language preferences.
- We have fixed the display issue where the name of the author of an accepted solution was not being displayed when the accepted solution was floated to the top of the page, when using Responsive.
- We have fixed the issue where the rich text editor was being displayed on mobile devices when it was supposed to be disabled.
- We have fixed the issue where XSS content stored in a TKB preview box was being displayed in a pop-up window when using the Masonry view on Responsive. This display issue has been fixed, and now the TKB preview box displays properly.
Review release notes and updates for all of our products! Select a label to browse by product or resource type.