Caches divided up into two groups: distributed and local. 'Low latency' is an
alias for local caches, while the standard `create()` call tries to get
distributed caches first, then local caches.
Memcache backend is set in `config.php`, with the keys `memcache.local` and
`memcache.distributed`. If not set, `memcache.distributed` defaults to the value
of `memcache.local`.
Doing this in the PHP code is not the right approach for multiple reasons:
1. A bug in the PHP code prevents them from being added to the response.
2. They are only added when something is served via PHP and not in other cases (that makes for example the newest IE UXSS which is not yet patched by Microsoft exploitable on ownCloud)
3. Some headers such as the Strict-Transport-Security might require custom modifications by administrators. This was not possible before and lead to buggy situations.
This pull request moves those headers out of the PHP code and adds a security check to the admin settings performed via JS.
This change will log all failures that prevent the CLI cronjob from happening to the database and display a warning to administrators when an error happened.
To test:
1. Configure some invalid CLI php.ini settings
2. Enable the CLI cronjob and run php cron.php
3. See the errors printed and also in the admin page
4. Configure the CLI settings correctly
5. Errors should be gone.
Fixes https://github.com/owncloud/core/issues/13994
The current code path may trigger situations where the LDAP application is not yet loaded and thus problems with the authentication appeared.
In previous versions of ownCloud the authentication mechanism manually loaded these apps which is why this affects ownCloud 8 and master only for my knowledge. (certainly not 6, maybe 7)
Backport to 8 might be something to consider.
Fixes https://github.com/owncloud/core/issues/14469
Somehow they got messed up. Because PHP does automatic type juggling this has worked before as well however it's not guaranteed that this might work in the future as well.
Due to a security hardening in 8.1 a missing value of empty trusted domains in the config would provoke an error as this was misused by a lot of users.
This caused a problem where the initial installation happened from another domain than 127.0.0.1 as in this case the domain was considered untrusted as no value was defined. However, this special case should not get intercepted.
To test:
- [ ] Installing ownCloud on 127.0.0.1 works
- [ ] Installing ownCloud on another domain / IP works
- [ ] When setting up ownCloud from 127.0.0.1 and accessing it from the domain above the trusted domain error should be shown if not specified in the config
Fixes https://github.com/owncloud/core/issues/14320
Thomas Müller
Morris Jobke
Robin Appelman
Georg Ehrke
Arthur Schiwon
Bjoern Schiessle
Hugo Gonzalez Labrador
Lukas Reschke
Jörn Friedrich Dreyer
Jenkins for ownCloud
Joas Schilling
Robin McCorkell
Clark Tomlinson