This documentation relates to an earlier version of the SharePoint Connector.
View

Unknown macro: {spacejump}

or visit the current documentation home.

Overview

There are two web parts with the SharePoint Connector:

  • Confluence Pages Tree View web part
  • Confluence Page web part

The Confluence Pages Tree View web part only shows a hierarchy of page names linked back to Confluence, so the content does not show any images. However, the Confluence Page web part shows the contents of a wiki page and therefore may show images. It is in this scenario where you may have an issue with images not displaying properly and showing up as broken links.

For more details on using these web parts, see Using the SharePoint Feature.

Broken Image Links Example

Broken image links look like the following:

Working Image Links Example

Here is the same image with the images links working properly:

Why Does This Happen?

When the Confluence Page web part requests page contents from Confluence, it does this using web services. The Confluence web services return the page contents in the form of HTML to the web part running on the SharePoint server and this in turn returns the HTML to the client's browser (to the user). This HTML contains simple text as well as links to images. Images are not embedded in the HTML (they can be embedded in a MIME email, but not standard HTML for a browser).

So, any wiki pages with images will have HTML that contains something like <IMG SRC="url_to_image">. If the image is an attachment to a wiki page, the URL to the image will point to Confluence. The SharePoint server knows how to authenticate and connect to Confluence web services, but the user's browser may not and it's the user's browser that is making a request for the image directly - the SharePoint server is not invovled.

In summary, a broken image link shows when either the URL to the image source is no longer available or if the access is denied for the user. The latter is the likely case for broken image links to images stored in Confluence, especially if you do not allow anonymous access to Confluence.

If you open a new browser instance and put the URL to a Confluence image you may find that you get redirected to the Confluence login page. This can happen on the request of a page, but when the browser is simply requesting an image within a page and gets authorization denied, it will show the broken link instead.

You can test out this scenario by doing the following:

  1. Opening up a new browser and navigate to a SharePoint page containing the Confluence Page web part that shows images within Confluence.
  2. Navigate your browser to Confluence. You should be taken to the login page where you can log in.
  3. Navigate your browser back to the SharePoint page you went to in the first step. The images should display fine.

Note that many browsers allow for multiple tabs and session state is maintained across all of those tabs (this is true with Firefox and IE7, but not IE8b2). In these situations you could log into Confluence on one tab and go to SharePoint on another and image would work find as log as you refreshed your page to SharePoint after logging into Confluence.

How Can I Prevent This?

Currently there are three primary ways to prevent this issue:

  • Remember my login on this computer
  • Adjust the Confluence session timeout
  • Use a more sophisticated authentication configuration to Confluence
  • Implement custom authentication for your environment
Remember my login on this computer

When you login to Confluence, there is a check box below the username and password fields for "Remember my login on this computer". If each user checks that, then a cookie is stored for the browser for the machine they are on and anytime they use that browser to go to SharePoint they will be able to request images from Confluence.

TODO

Is there an expration on this cookie?

Adjust the Confluence session timeout

This is more of a workaround, but you can increase the session timeout such that once the user is logged into Confluence, they stay logged in for an extended period of time. This would only reduce the likelihood of broken link images, but not remove it. It would basically reqiure that the user already have logged into Confluence recently before viewing a wiki page with Confluence images within the Confluence Page web part inside of SharePoint.

TODO

Does this also increase the cookie timeout and not just the current browse session? If it does not do anything with cookies then we don't need to mention it.

Use a more sophisticated authentication configuration to Confluence

In Authentication Configuration several options are discussed in terms of how to authenticate to Confluence. Basically, two methods are discussed:

  • NTLM (either through Tomcat + IIS or through JCIFS)
  • Microsoft SSO

If you are able to use NTLM with Confluence, then most browsers will negotiate authorization for images as needed assuming that the browser has been setup with the Recommended Browser Settings.

With Microsoft SSO, the SharePoint page returned to the client will pre-authenticate to Confluence in an attempt to prevent image links from showing up as broken. In essence there is script running on the page that will cause the browser to authenticate to Confluence before showing the contents of the Confluence Page web part. Note that from time to time this does not work due to the asynchronous nature of the requests. A simple refresh of the page fixes the problem if broken images are shown, however.

Implement custom authentication for your environment

Some enterprises already use custom authentication with Confluence. They may have a 3rd party single-sign on product such as SiteMinder and want to make sure Confluence and SharePoint are integrated with it. In doing so, you can force requests to go through your own network device (e.g., ISA Server) which would redirect the request such that any request to SharePoint would ensure that there is a Confluence session established.

Chart Macro Issues

The {chart} macro basically generates an image within Confluence and shows that image to users in the wiki page. So, this has the same potential for broken image links as described above.

One additional caveat is that the chart macro generates image links per individual and those links are secured such that only that individual can access them. What this means is that the following scenario will result in a broken image link for a chart within the Confluence Page web part:

  1. Log into Confluence with your browser using one account (e.g., user1)
  2. Navigate in the same browser to SharePoint and log in with a different account (e.g., user2)
  3. Use the same browser within SharePoint to view a Confluence Page web part showing a wiki page that has a chart macro on it.

The HTML image link to a chart image provided to your browser through the Confluence Page web page will be for your SharePoint user (user2). However, your browser is authenticated to Confluence using a different user (user1), therefore access is denied to the image and the image is shown as a broken link.

Enhancement to Prevent Broken Images

There is one primary feature request that may correct this issue once and for all: CSI-280. In essence, any Confluence image link from the Confluence Page web part would point back to SharePoint and the SharePoint server would go get the image from Confluence and stream it back to the client browser on demand. Feel free to vote on this issue if it is important to you. You will need to log in (you can create a log in) in order to vote.

  • No labels