Using forefront over confluence prevents some actions from completing

[Brett Ryan]

We are making confluence available to remote users through a Microsoft product called Fore Front, it works fine for viewing content however editing is not working correctly.

The editor starts fine however attempting to preview or bring up the macro browser does not work and results in an error 500 (code 64: Host not available).

Are there any other ports etc that we need to enable within forefront to client connections?

[Joe Clark · Accepted solution]

Hey Brett,

You only need the HTTP port for Confluence (eg. 80 or 8080).

Make sure your Confluence Base URL is set correctly. Because users are going to access Confluence via ForeFront, you need to edit the base URL so that it points to ForeFront.

Details here: https://confluence.atlassian.com/display/DOC/Configuring+the+Server+Base+URL

Some of the dynamic parts of Confluence use the Base URL to call-back in to Confluence after the page has loaded (for example, in the editor). If the base URL is different to the URL by which the page was originally loaded, these background requests will not be able to authenticate against the Confluence server and will fail.

[Brett Ryan]

It turned out this was a misconfigured forefront which I did not have control of. I'm sketchy on the detaisl but it had to do with how forefront was redirecting from the client.

Our confluence machine is fronted by Apache/AJP, this was originally running on HTTP internally. However forefront needs to run on HTTPS. To try resolve the problem I set the apache configuration to redirect all requests from HTTP to HTTPS which then caused external requests to end up in an infinite redirection loop, aha, this I could see where the problem was.

It turns out that forefront was misconfigured, I'm not sure of how because that area of our system I do not have access to. The basics of the problem were as follows:

1. Forefront accepted a request on HTTP and redirected to HTTPS (confluence/apache has not seen the request yet).
2. Forefront authenticates the user and proxies the request off to apache
3. Apache accepts the request on port 80 (http) and sends a redirect for https.
4. This redirect then gets sent to the browser which obligingly redirects to https (which it was already at)
5. Forefront takes the request on port 80, then forwards the request to apache again, on port 80 and we end up at step 3 again.

I had a rather frustrated infrastructure administrator trying to solve the forefront problem, which was eventually solved and all is now peachy :)

I provide this to anyone else experiencing proxy type misconfigurations to help identify what the problem is.

[Joe Clark]

Thanks for taking the time to provide your answer back to the community! :-)