Trying to use subsonic with SSL, and I have been having an issue with subsonic's internal redirection. For instance when you try to go nowPlaying.view, it redirects to main.vew, and the redirection is to HTTP, it drops the HTTPS, which breaks the site. (Also there are issues with the Now playing info on the right of the main.view, with broken images, links, also using HTTP, instead of HTTPS). Is there any way to force subsonic to use HTTPS urls internally, or to possibly drop the http://, https://, and use relative urls?

I am running Ubuntu 8.04 and Tomcat 5.5 with SSL. I did not experience any of the described problems. I also had Tomcat and SSL with previous Ubuntu versions and WinXP running. Subsonic always worked great with SSL.

I should clarify, in my case I run nginx in front of tomcat. If I allow HTTP traffic, the pages will forward properly, and I don't have any difficulties. It'll use SSL from streaming and most of the pages, but certain elements, like the album images in the now playing sidebar are transmitted over regular HTTP. I think SSL is broken behind a proxy because of the absolute urls. It'd be great if there was a switch to force it to use HTTPS for all the urls.

I've tested the new stable release (3.6) and there is some improvement with proxy support, since the embedded player is now trying to reach my server instead of localhost (I'm using Subsonic behind nginx; Jetty is listening on localhost, port 80 and nginx is making it reachable with SSL support on port 443).

There is still an issue, though. I've seen in my firewall logs that the embedded flash player is trying to reach my server on port 80 (HTTP) instead of 443 (HTTPS).

I had a quick look in the source code and I found this (file StringUtil.java, function rewriteUrl):

I've having the same problem listed above (that started this topic). Slightly different configuration. My Ubuntu Subsonic host lies behind an ISA firewall. IDS accepts connections on a non-standard SSL port and mask forwards the traffice to the Subsonic at 8080. But Subsonic tries to change the link and the SSL is then broken, the whole site gets screwy after that.

SubSonic running on a Windows 2003 server, listens on 8082 HTTP port within local area network.
ISA 2006 listening on 443 SSL port within LAN and public DMZ, redirects (publishes) traffic to the HTTP SubSonic website.

Everything works fine except for the embedded player when I'm using the ISA published SubSonic website (I get no buffering, so I can't play anything).
Everything works OK when I log on to SubSonic directly from the LAN.
If I set ISA to listen on 80 HTTP port, everything works OK too.

I'd like to use SSL on ISA, so if anyone has a clue to override this behavior, I would be very grateful!

Vasteel, I've been able to get streaming working fine. Its just that the SSL breaks when the album art is published without ssl.

Try this: run subsonic inside of tomcat (the WAR version is provided here also). then publish a certificate from your CA (export key too), place the cert in a folder on the server and edit the tomcat secure config (server.xml). here is what mine looks like:

restart tomcat Now my subonsic server is listening on port 4330 and secured using a trusted certificate (neccessary for ISA to use this as a published site. This should be the same/similar using windows.

ISA: create a weblistener on 443, use the same certificate (or at least one that contains your public address). then publish a site using ssl bridging, uses your new listener, and recognizes a certain string (/subsonic/* for example.)

This works great for me, streams over ssl everywhere. i was a bit vague, so let me know if you need any more help.

This still seems to to be an issue in the latest version (3.. I've been trying to get subsonic working through apache's ssl authentication, but experience the same thing as the parent poster...it appears there are hard-coded http links which break my https connection when they are hit.

If relative URLS are not going to be used, I was considering using http://apache.webthing.com/mod_proxy_html/ to change the http references on the fly. I was also looking into using tomcat's ssl, but I like the idea of keeping everything together in apache.

anitract wrote:This still seems to to be an issue in the latest version (3.. I've been trying to get subsonic working through apache's ssl authentication, but experience the same thing as the parent poster...it appears there are hard-coded http links which break my https connection when they are hit.

If relative URLS are not going to be used, I was considering using http://apache.webthing.com/mod_proxy_html/ to change the http references on the fly. I was also looking into using tomcat's ssl, but I like the idea of keeping everything together in apache.

Anyone have a different work around?

I am also have similar issues, I have apache proxying from another computer and then out to the internet, it works cept for when you login it drops the https for http on login and logout, also the nowPlaying page gives a 404. Adding the (s) to http when i get the 404 fixes the issues and it continues on, except for the now playing page, which just gives the 404 and tries to go back to the main view like stated above.

Thanks for any help on this.

Edit: also just noticed that the Settings page behaves like the nowPlaying page.

I'd like to echo the https -> http problems above. I have SSL working on a Windows 7 install using a LightTPD server as a proxy (mod_proxy). Subsonic v3.9 keeps changing https to http after login and on other assorted pages, Settings for example.

The above login.jsp patch does not work for me, in fact it breaks pretty much everything.

I'm going to assume this needs to be fixed before any of the iPhone or Android mobile apps can reliably implement SSL. I'll be registering shortly as this server works so beautifully on my mobile devices. I hope this can sorted out as well.

Sorry to bump... but is this in your queue to be fixed for the next version of Subsonic? Z-Subsonic will have SSL support in v1.5 which should make SSL configurations more popular for users. This bug seems to be a final hurdle to get it working for the web interface as well.