X-Forwarded-For headers in new security logging

[cowieson]

Firstly - great work on the new version (5.3) of Subsonic - loving it so far.

This release brings two features I had been hoping for - namely the use of custom URLs other than *.subsonic.org for sharing, and the implementation of login-failure logging so as to facilitate the use of tools like fail2ban.

The latter is a great step in the right direction - but currently is fairly basic in so far as it will only log the correct remote IP address if the connection is being made directly - if the Subsonic instance is behind a reverse proxy (as I suspect many are, besides myself), currently it would seem that Subsonic does not parse out/correctly log the 'X-Forwarded-For' headers from the web server forwarding the remote IP address; the logged IP address is the localhost IP (typically 127.0.0.1 if bound to IPv4) which of course would end up with fail2ban inadvertently banning the localhost from accessing itself!

If support for the correct logging of this header if it exists could be added, so that Subsonic would then log the remote IP not the localhost IP, it would be much appreciated - and pretty much cover all bases as regards possible setups with fail2ban or similar.

[daneren2005]

For Sindre I have a similar setup and was able to get it to work via REST requests with https://github.com/daneren2005/Subsonic ... dac1845436. I can't figure out how to get it to work via standard web logins due to the fact that it is getting the ip from WebAuthenticationDetails and that class does not expose the underlying request object. From a little googling it appears that you could implement your own version of that class and override getRemoteAddr to return something similar to how I do it in the commit for REST requests. I have never programmed in Jetty though so I'm not sure how all of the configuration for that is supposed to work.

[cowieson]

*bump*

It would be fantastic if this could be included in the upcoming Subsonic 6 release - to my understanding, it should be a (relatively) trivial inclusion as it's basically just logging received HTML headers.