This is ugly as hell. But if we directly access `\OCP\IUserSession::getUser` here PHP throws a segfault on some servers:
```
gdb /usr/sbin/apache2 --batch --quiet -ex "run -f /etc/apache2/apache2.conf -DNO_DETACH -DONE_PROCESS -DDEBUG $defines" -ex "quit"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.6. Set the 'ServerName' directive globally to suppress this message
warning: the debug information found in "/usr/lib/debug//usr/lib/php5/20121212/mysql.so" does not match "/usr/lib/php5/20121212/mysql.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib/php5/20121212/mysql.so" does not match "/usr/lib/php5/20121212/mysql.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug//usr/lib/php5/20121212/mysqli.so" does not match "/usr/lib/php5/20121212/mysqli.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib/php5/20121212/mysqli.so" does not match "/usr/lib/php5/20121212/mysqli.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug//usr/lib/php5/20121212/pdo_mysql.so" does not match "/usr/lib/php5/20121212/pdo_mysql.so" (CRC mismatch).
warning: the debug information found in "/usr/lib/debug/usr/lib/php5/20121212/pdo_mysql.so" does not match "/usr/lib/php5/20121212/pdo_mysql.so" (CRC mismatch).
[New Thread 0x7fffdd206700 (LWP 28386)]
[Thread 0x7fffdd206700 (LWP 28386) exited]
[New Thread 0x7fffdd206700 (LWP 28387)]
[New Thread 0x7fffdc975700 (LWP 28388)]
Program received signal SIGSEGV, Segmentation fault.
zend_parse_parameters (num_args=2, type_spec=type_spec@entry=0x7ffff3f85227 "s|s") at /build/php5-pO28mL/php5-5.5.9+dfsg/Zend/zend_API.c:923
923 /build/php5-pO28mL/php5-5.5.9+dfsg/Zend/zend_API.c: No such file or directory.
A debugging session is active.
Inferior 1 [process 28382] will be killed.
Quit anyway? (y or n) [answered Y; input not from terminal]
```
I'm still struggling to get a minimal example of this (also considering that it doesn't happen on every system :party). Anyways, it's a functional workaround until I determined the root cause… (also given the fact that patches may never be backported to distributions 🙈
* Read available l10n files also from theme folder
The old behaviour was that only languages could be used for an app
that are already present in the apps/$app/l10n folder. If there is
a themed l10n that is not present in the apps default l10n folder
the language could not be used and the texts are not translated.
With this change this is possible and also the l10n files are
loaded even if the default l10n doesn't contain the l10n file.
* Inject server root - allows proper testing and separation of concerns
in order to create a 1:1 copy of a file if a version gets created
we need to store this information on copyBetweenStorage(). This
allows us to by-pass the encryption wrapper if we read the source file.
The code path called when using external storage with WebDAV is using `\OC\Files\Storage\Wrapper\Encryption::getMetaData` which did not contain the actual encrypted version inside the cache entry version. This lead to the following:
1. User uploaded a file
2. File is created and `\OC\Files\Storage\Wrapper\Encryption::getMetaData` is called. It has an empty `encryptedVersion` but sets `encrypted` to either `true` or `false`.
3. The call when updating the file cache will use the old version.
Fixes#23536
The new sharing code is much stricter in checking permissions. However
for non moveable mounts the permissions UPDATE+DELETE are not reported
on the mount point.
This is just a quick fix.
* Updated unit tests
There are authentication backends such as Shibboleth that do send no Basic Auth credentials for DAV requests. This means that the ownCloud DAV backend would consider these requests coming from an untrusted source and require higher levels of security checks. (e.g. a CSRF check)
While an elegant solution would rely on authenticating via token (so that one can properly ensure that the request came indeed from a trusted client) this is a okay'ish workaround for this problem until we have something more reliable in the authentication code.