This adds the 'airsonic.rememberMeKey' system property (can be set from
command-line with `-Dairsonic.rememberMeKey=<value>`) as well as a
'RememberMeKey' setting in airsonic.properties, so that the key used for
generating 'remember me' tokens can be persisted across server restarts.
It also adds a default, insecure key in case we are running in
development mode with the 'airsonic.development' property set.
This page wasn't linked anywhere, and was
allowing an administrator to issue arbitrary sql
comments, and was vulnerable to reflected XSS.
We should get rid of it. If you really want to issue
SQL commands, just ssh to your instance and do it from here.
In case of exceptions, Airsonic logs the full URL that triggered it
since 417583cc, including possibly sensitive query parameters such as
the authentication password/tokens passed to the Subsonic API.
This replaces the value set for this parameter in the URL by the
"<hidden>" string.
Because Double Brace Initialization (DBI) creates an anonymous class with a
reference to the instance of the owning object, its use can lead to memory
leaks if the anonymous inner class is returned and held by other objects. Even
when there's no leak, DBI is so obscure that it's bound to confuse most
maintainers.
When Tomcat is not available (for example, when using Jetty), the
ClientAbortException is not available either, causing an error when
starting the server.
This commit fixes that, and instead catches that exception (or its Jetty
equivalent) via reflection.
When streaming, log messages now show the URL and IP of the originating
request, so that it's easier to determine what client is listening to
something on the server.
The `ClientAbortException` exception indicates that the connection was
closed by the client, usually for something the server can do nothing
about (e.g. navigating outside of the page while it's loading).
Since this error happens often, this commit displays shorter error
messages when it does, without a large stack trace.
All other exceptions are handled just as before.
Since Spring's default remember-me technique is
terrible security-wise (`user:timstamp:md5(use:timestamp:password:key)`),
we should at least use a random key, instead of a fixed one,
otherwise, and attacker able to capture the cookies
might be able to trivially bruteforce offline
the password of the associated user.
Previously, lost passwords were generated via
org.apache.commons.lang.RandomStringUtils,
which is using java.util.Random internally.
This PRNG is has a 48-bit seed, that can easily be bruteforced
if an attacker is able to get the PRNG's output, for example
but resetting their own account multiple times,
leading to trivial privileges escalation attacks.
This commit makes use of java.security.SecureRandom
instead.
I threw airsonic at IntelliJ's IDEA analysis,
and asked it to flag what could be modernized
for Java > 5.
- foreach instead of for…
- I added some null-deref checks
- Integer.ValueOf, since Integer(…) is deprecated
- Contextual try
- Objects.equals instead of handcrafted comparisons
- StringBuilder instead of StringBuffer
- Removal of outdated/wrong javadoc comments
This will only affect the (embedded/legacy) HSQLDB driver. Even though
cff97ea9 should prevent the db log from getting uncontrollably large,
the 'Clean-up database' and 'Scan' actions will additionally force a
checkpoint to ensure this happens on big operations.
As per #548, #723, and tsquillario/Jamstash#131, the current method of
estimating `Content-Length` creates various problems.
However, if headers such as `Accept-Ranges` is omitted, clients will only
use the first connection, which is `Transfer-Encoding: chunked`, and no
`Content-Length` is necessary.
Doing this has the side effect that (at least on the web player) seeking
to a specific time is no longer possible, thus this was made an opt-in
option.
Signed-off-by: WillyPillow <wp@nerde.pw>