Images remain http after moving Confluence to https

[Kristian Wright]

Hello all!

I first installed Confluence 4.3 locally and ran it via http on port 8090. During this time I added a lot of pages with images in the content.

Recently I moved Confluence to a server, and secured it behind Apache. Everything is working well aside from the images. I access my wiki via https://wiki.fakesite.com/..., and all content comes through but no images render. Firebug shows me that everything is being served via https besides the images which are still http://wiki.fakesite.com:8090/download/attachments/....

If I change the image url to https and drop the port in another browser tab, then the image is shown correctly. So I'm happy that they are still there and can be served from Confluence.

I've had a look in the admin section but I don't see anything specific to the URLs of images. BTW, my baseURL is set to https://wiki.fakesite.com, which I've read it should be.

Does anyone know of a way to fix the image URLs without needing to delete and re-add each image? There must be something I'm missing here...

Thanks,

K

[Tiago Comasseto · Accepted solution]

There is also a chance that the URL of the images have been hardcoded into Confluence's database when they were inserted. In this case you can check this executing this query:

select * from BODYCONTENT where body like '%http://wiki.fakesite.com:8090%';

And then execute the following query to change the URL:

UPDATE BODYCONTENT 
   SET BODY = REPLACE(BODY,'<old_string>','<new_string>');

• <old_string>: string to search on the field BODY, which will be replaced for '<new_string>'.
• <new_string>: string which will replace '<old_string>'

I hope this helps.

Cheers

[Kristian Wright]

Worked a treat! Thanks for that Tiago.

I'm still going to raise a defect though - I should not have to do this. I would think that the Server Base URL in the admin section would be used for things like this. The fact that the URLs are clearly saved into the DB regardless of the Server Base URL is something I think should be addressed.

Either way, it's working now! Much appreciated!

Cheers,

K

[Tiago Comasseto]

Hi

I've set Confluence to run behind Apache using this instructions. My httpd.conf is set as below:

# Put this after the other LoadModule directives
# LoadModule proxy_module /usr/lib/apache2/modules/mod_proxy.so
# LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so
 
# Put this in the main section of your configuration (or desired virtual host, if using Apache virtual hosts)
ProxyRequests Off
ProxyPreserveHost On
SSLProxyEngine on
 
<Proxy *>
    Order deny,allow
    Allow from all
</Proxy>
 
ProxyPass /confluence http://localhost:8090/confluence
ProxyPassReverse /confluence http://localhost:8090/confluence
<Location /confluence>
    Order allow,deny
    Allow from all
</Location>

And I've modified my server.xml to this:

<Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8090" minProcessors="5"
                   maxProcessors="75"
                   enableLookups="false" redirectPort="8443" acceptCount="10" debug="0" connectionTimeout="20000"
                   useURIValidationHack="false" URIEncoding="UTF-8"
		   proxyName="example.com" proxyPort="443" scheme="https"
		   />

Using this configuration everything works fine, including the images. You may compare this configuration with yours.

I hope this have helped.

Cheers

[Kristian Wright]

Thanks Tiago,

I have almost the exact same setup aside from the server.xml changes - I tried them, but I have issues with the proxyName (it gets confused with my ISP). However I don't think this is the problem.

As a test, I just edited one of the pages containing images, added a brand new image, and saved it. The new image displays correctly. It has a URL starting with http://wiki.fakesite.com, withbut the other broken images remain on the old http://wiki.fakesite.com:8090.

So I'm confident that this setup is correct and working, it just seems that the image URLs that were created before the move are not updated.

I'm thinking I might raise a bug for this...

Cheers,

K