FAQ

Is Lockpoint Server/Data Center susceptible to the CVE-2021-44228 (Log4Shell) Vulnerability?

No. Lockpoint does not bundle the impacted Log4j module, although it does make use of the Log4j implementation that is included in Confluence. Atlassian has indicated that Confluence is not vulnerable to this exploit in its default configuration, and so long as Confluence remains not vulnerable, neither is Lockpoint. This statement applies to all released versions of Lockpoint (1.x, 2.x).

After upgrading to Confluence 7.3+, attachments are not automatically unlocked after editing

Starting with Confluence 7.3, Atlassian made changes to the editing process with the Atlassian Companion. In previous versions of Confluence, the "Edit in App" feature permitted users to edit one single attachment at a time, and once changes were made to the attachment, it was uploaded, saved and unlocked at the same time.

In Confluence 7.3+, the Atlassian Companion permits users to edit multiple attachments on the same page simultaneously. In addition, it permits multiple changes to be made to the same attachment in one session. For example, a user can edit an attachment, save, upload the changes, make another change to the same attachment, save, and upload again. To function correctly with this workflow, Lockpoint cannot immediately unlock attachments after the first upload, since the user may not be finished editing.

Instead, we worked with Atlassian to ensure that Lockpoint was integrated with the "X" (close) button in the Atlassian Companion attachment list. After an attachment is uploaded to Confluence, it remains in the Atlassian Companion window and further edits are still permitted. As soon as the user clicks the "X" button, the attachment is removed from the attachment list and no further editing is allowed. When the "X" button is clicked, Lockpoint will automatically unlock the attachment, and the lock status will be updated in the browser window, sometimes after a short delay.

The full locking and unlocking process is described in our documentation for the Edit in App feature.

I received the message from Confluence: "You must first lock the file before it can be edited"

Lockpoint works in conjunction with Confluence to ensure that changes to existing files or attachments cannot be accidentally overwritten by other users.

If you are trying to upload an attachment to Confluence, but the attachment already exists on the page and it is not locked by you, Confluence will prevent the upload and display the error: "You must first lock the file before it can be edited".

To upload the attachment, you can proceed in one of two ways:

1. Navigate to the "... -> Attachments" page (or use the Attachments macro), then click the "Lock to Edit" button/link. The attachment will then be checked out to you, allowing you to upload the attachment. When you have finished updating the attachment, use the Unlock button/link to release the attachment.
2. Alternatively, ask your Confluence administrator to enable Smart Locking. With Smart Locking enabled, you will be able to upload new copies of existing attachments without locking them, just so long as no other users on your system currently have the attachment locked. 

Enabling Lockpoing

Lockpoint cannot be enabled

If Lockpoint 1.7.0+ cannot be installed or enabled in your system, you may see an error message like this in the system logs:

Caused by: java.lang.IllegalStateException: Cannot
execute atlassian-spring-scanner-runtime: plugin has an
extra copy of atlassian-spring-scanner-annotation classes,
perhaps embedded inside the target plugin
'com.arsenale.plugins.lockpoint'; embedding scanner-annotations
is not supported since scanner version 2.0. Use
'mvn dependency:tree' and ensure the atlassian-spring-scanner-annotation
dependency in your plugin has <scope>provided</scope>, not 
'runtime' or 'compile', and you have NO dependency on 
atlassian-spring-scanner-runtime.

The root cause of this problem is a different misconfigured plugin installed in Confluence. This problem can impact a number of other plugins/apps other than the plugin that is misconfigured, and despite the error message above, it is not a Lockpoint-specific issue. To get Lockpoint to load correctly, you may need to locate the misconfigured plugin (see CONFSERVER-55916 and the related comments), temporarily disable that plugin, and then enable Lockpoint. The long-term solution is to ask the vendor of the other plugin to correct the issues in their product. Other plugins that are known to provoke this issue include:

• Tooltip for Confluence v1.2.4
• Atlassian Playbook Blueprints

If you need assistance tracking down the misconfigured plugin, please contact Cenote Support.

Edit in Office

Edit in Office does not work, or Office documents open as read-only

The Atlassian Office Connector and Atlassian WebDAV add-ons, which are built into Confluence, are required to use the Edit in Office feature of Lockpoint. Unfortunately, users sometimes experience compatibility issues between the Atlassian Office Connector and later versions of the Microsoft Office suite. The root cause is later versions of Office do not perform basic WebDAV authentication over unencrypted connections, but Confluence does not support any other type of WebDAV authentication.

If you are having problems with Edit in Office not working, documents opening in read-only mode, or attachments opening as blank documents, you are probably experiencing this issue. 

We are aware of a number of workarounds that may be used to alleviate these issues.

If that does not correct the problem, try one of the following workarounds. Depending on your specific configuration of client OS and office versions, you may need to implement  more than one  of these workarounds.

This solution is the most straightforward, but depending on your environment, it may involve additional administrative work. If Confluence is accessed over an HTTPS connection, Office applications should be able to authenticate properly.

Solution 2: Ensure that your Confluence site is listed in the "Trusted Zone" in Internet Explorer

In Internet Explorer, select Tools > Internet Options, select the Security tab, click the Trusted Sites icon, and click "Sites". Add the URL of your Confluence server to the dialog box (disabling the https requirement, if necessary), then Close and Save the dialog.

Solution 3: Enable Office Connector "pathauth" authentication and disable HTTP-only cookies

i) In Confluence, go to the Office Connector Configuration in the admin section and enable "Allow authentication tokens in the URL path". 

ii) Follow the "Workaround" advice in this Confluence knowledge base article in order to work around bugs that prevent the pathauth authentication from working properly.

Solution 4: Apply registry edits to all Windows client computers

Apply the registry edits from Microsoft KB 2123563 to each client that will be accessing Confluence.

Note that this article specifies that two registry edits are required per machine if you are using Office 2010.

Solution 5: Repair the Office installation on client  computers

On Windows 7, for instance:

• Click Start > Control Panel > Programs > Programs and Features.
• Click the Office program you want to repair, and then click Change.
• In the Office window that appears, click Repair > Continue.

You may need to restart the computer on completion of these steps.

Solution 6: Contact Atlassian Support

Although Lockpoint adds locking support to WebDAV, the main WebDAV add-on (and the related Office Connector add-on) are provided by Atlassian as part of Confluence. If the Edit in Office link does not work properly with Lockpoint installed, chances are that it also does not work properly when Lockpoint is disabled. In this scenario, if you open a support ticket with Atlassian, they will be able to provide more-specific advice regarding your particular Confluence installation and your organization's OS and Office versions.

While editing a file with Edit in Office, Confluence does not show the file as locked

If you're able to successfully use Edit in Office to edit documents from Confluence and save them back to the Confluence page from the Office application, then Cenote Lockpoint should be correctly locking and unlocking those documents in tandem with the start and end of your editing session.

However, the actual lock status of the Confluence attachment may not be reflected on the Confluence page until you manually reload/refresh the page in your browser. (If you are instead using the Edit in App feature available in newer versions of Confluence, the lock status will be refreshed automatically.)

To verify that Cenote Lockpoint is properly locking your attachments during Edit in Office, click Edit in Office to open the attachment, and while the file is open for editing, click on the browser reload/refresh button for that Confluence page.  You should see the attachment then properly marked as locked on the Confluence page.  

Similarly, to verify that Cenote Lockpoint is properly unlocking your attachments on completion of editing an attachment in the Office application, save your changes to the attachment and close the Office application.  Click on the reload/refresh button in your browser for that Confluence page.  You should see the attachment now marked as unlocked again on the Confluence page.

How do I get Lockpoint and Confluence's Edit in Office functionality working with Google Chrome?

In Confluence 6.x, Google Chrome on Windows may work with Edit in Office, but this feature is undocumented. However, the Edit in Office feature will not work with Chrome and Microsoft Project or Microsoft Visio files.

For Confluence 6.10  or below, a reasonable workaround for Google Chrome users on Windows (only) is to install the IE Tab for Chrome extension in your browser, which integrates an Internet Explorer rendering engine into Chrome. With that extension installed, if you want to edit a Confluence attachment in Office, open the Confluence page in an IE tab in Chrome and then click on Edit in Office.

For Confluence 6.11 and above, the Edit in Office feature has been replaced by Edit in App. Lockpoint fully supports Edit in App across all browsers and file types. Confluence administrators can optionally re-enable the Edit in Office functionality on those versions of Confluence by enabling a Confluence "dark feature". Lockpoint also fully supports locking with the Edit in Office dark feature.

How do I disable the Edit in Office button/link?

If you wish to disable the Edit in Office button on a system where Lockpoint is installed, follow the steps listed below.

Lockpoint overrides the functionality of the Atlassian Office Connector, so these instructions are different from systems where Lockpoint is not installed.

1. select Toolgear » Add-Ons
2. select "User-installed" add-ons in the dropdown (if applicable),
3. look through the list of user-installed add-ons to locate Cenote Lockpoint, then click the entry to expand,
4. click the "xx of yy modules enabled" link
5. hover the mouse over the line that reads "Edit office document link on attachment page (with pathauth)" and click the Disable button, and
6. hover the mouse over the line that reads "Edit office document link on attachment page" and click the Disable button.

WebDAV Locking

In WebDAV locking of attachments, why is the actual file locking duration different than what the client requested?

WebDAV locking does not currently use the specific duration requested in client LOCK requests. Instead, the administrator-configured default (as defined in Email Notifications) is used for all files.

Is there any way via WebDAV to lock an entire tree of Confluence content?

Cenote Lockpoint only locks individual files/attachments. It does not currently support locking an entire tree of Confluence content via WebDAV. In practice, this feature is used rarely and most common WebDAV clients (including Microsoft Office) do not use this feature.

However, using the Attachments macro built into Confluence, you can use the Lock All and Unlock All links to lock all attachments shown in the macro.

Drag and Drop Locking

Why am I getting a cryptic error message when I drag and drop a file onto an Attachments page to upload it?

If the file is not locked by you, Internet Explorer will display a less-than-helpful message after the file upload completes. While the file will be appropriately protected, the message may be confusing to users. To overwrite an existing file, simply lock the file yourself and try the drag-and-drop upload again.

This issue occurs as a result of a known compatibility issue between the Atlassian Drag and Drop add-on (which processes the error message generated by Cenote Lockpoint) and Internet Explorer. This bug in Atlassian's Drag and Drop add-on only impacts Internet Explorer, so users who use a different web browser will see a relevant error message.

Administration

Why are there messages in my Confluence log referring to "confluence.sections.attachments", and why does Lockpoint disable modules in the system Attachments plugin?

As a part of standard system operation, Lockpoint versions prior to 1.6.9 automatically disabled some built-in modules in the system Attachment Actions Plugin when Lockpoint was installed. These modules are responsible for displaying certain attachment-related buttons, such as the Properties and Delete buttons, as well as the Edit in Office button for the Office Connector. Lockpoint 1.6.9 and above no longer perform this disablement.

While these modules were designed to be re-enabled when Lockpoint was uninstalled, in a limited set of circumstances when upgrading to a newer version of Lockpoint, these modules could have inadvertently remained disabled.

It is possible that long-time users of Lockpoint (who have, at any time, ever installed Lockpoint 1.6.8 or prior on their systems) may experience a situation in which the Attachment Actions plugin or its modules were disabled by Lockpoint 1.6.8 or prior and those modules remained disabled. A similar scenario can apply to certain modules in the Office Connector. The disablement of these modules would not be noticeable to the user while Lockpoint (any version) was installed, since Lockpoint replaces this system functionality.

If you find that the attachment Properties, Delete, Edit in Office, or other buttons disappear when you uninstall or disable Lockpoint, and if you have ever had Lockpoint 1.6.8 or earlier installed, it is likely that this issue impacts you. Note that the modules in these system plugins cannot generally be re-enabled through the Confluence App Manager, so the issue cannot be fixed through the UI.

A fix for this issue was included in Lockpoint 1.8.0, which will attempt to automatically re-enable any the specific system modules that were disabled by earlier versions of Lockpoint. To apply this fix, install Lockpoint 1.8.0 or higher, ensure that it has a current license (installing a free 30-day evaluation license if needed), and wait for five minutes after activation. Lockpoint 1.8.0 and above automatically attempt to detect and remedy this situation a few minutes after installation. Once the Attachment Actions modules have been re-enabled (which should be noted in the Confluence logs), the problem has been corrected and Lockpoint does not need to remain installed. This is a one-time operation that will cure the state of the modules and it does not need to be repeated.

A symptom of the problem is a log message that looks like this on Confluence startup:

WARN [main] [atlassian.plugin.manager.DefaultPluginManager] addPlugins
System plugin is disabled: confluence.sections.attachments

WARN Lockpoint found the following plugin (module) disabled, and enabled it: <PLUGIN>.
To suppress this enablement, set JVM startup parameter
-Dcom.cenotelabs.lockpoint.disablePluginStateEnforcement=true

Solution #3

If you still have difficulty after following these steps, please contact us.