| Age | Commit message (Collapse) | Author |
|---|
|
owncloud/backport-15772-no-permission-restriction-for-owner
[stable8] Backport 15772 no permission restriction for owner
|
|
|
|
* add $success to the updateEnd hook
* add new return code for a update failure
* add exception class to failure hook message
|
|
Conflicts:
core/js/tests/specs/shareSpec.js
|
|
Conflicts:
core/js/share.js
|
|
[stable8] Backport scrollbar fixes
|
|
Add check for availability of /dev/urandom
|
|
|
|
|
|
|
|
|
|
This reverts commit bb79a6b4f0a94e82c723b90d193a4391f725fb23.
|
|
[stable8] Fix to make sure expiration date is properly set
|
|
Backport of https://github.com/owncloud/core/pull/16565 to stable8
|
|
[stable8] fix theme in IE8 and IE9
|
|
|
|
This did not happen correctly when the password was enforced since a
different code path was taken.
* moved generation of the default date string to separate function
* added unit test
|
|
|
|
Stable8 backport 15489
|
|
|
|
Conflicts:
core/templates/login.php
lib/base.php
|
|
* add ability to filter for mimetype
* fixes #15526
* fixes #11563
|
|
Very hacky backport of https://github.com/owncloud/core/pull/15541 - I changed the code path to use OC_Mail instead the OCP pendant since I didn't want to modify the public API. (OCP\Util::sendMail() is anyways deprecated with 8.1)
|
|
fix #10544
|
|
This removes the recently introduced hard dependency on cURL for 8.0, for 8.1 it will still stay there.
Instead a warning will now be shown to the user asking to install the PHP cURL extension within the administrative interface of ownCloud.
|
|
This makes repair errors and warnings visible for the user when
upgrading on the command line or in the web UI.
|
|
[stable8] Verify CSRF token already in update.php and not the EventSource code
|
|
|
|
Issue report:
> Hum, well I upgraded the package then visited the web interface to
trigger the update and it failed; the UI would say there was a
possible CSRF attack and after that it'd be stuck in maintenance mode.
Tried a few times (by editing maintenance to false in owncloud.conf)
and same result each time.
That smells partially like an issue caused by our EventSource implementation, due to legacy concerns the CSRF verification happens within the EventSource handling and not when the actual endpoint is called, what happens here then is:
1. User has somehow an invalid CSRF token in session (or none at all)
2. User clicks the update button
3. Invalid CSRF token is sent to update.php - no CSRF check there => Instance gets set in maintenance mode
4. Invalid CSRF token is processed by the EventSource code => Code Execution is stopped and ownCloud is stuck in maintenance mode
I have a work-around for this problem, basically it verifies the CSRF token already in step 3 and cancels execution then. The same error will be shown to the user however he can work around it by refreshing the page – as stated by the error. I think that’s an acceptable behaviour for now: INSERT LINK
To verify this test:
1. Delete your ownCloud cookies
2. Increment the version in version.php
3. Try to upgrade
=> Before the patch: Instance shows an error, is set to upgrade mode and a refresh does not help
=> After the patch: Instance shows an error, a refresh helps though.
This is not really the best fix as a better solution would be to catch such situations when bootstrapping ownCloud, however, I don’t dare to touch base.php for this sake only, you never know what breaks then…
That said: There might be other bugs as well, especially the stacktrace is somewhat confusing but then again it installing ownCloud under /usr/share/owncloud/ and I bet that is part of the whole issue ;-)
|
|
* fixes #13968
* fix variable already defined
|
|
|
|
Conflicts:
lib/private/app.php
|
|
|
|
Backport #14338 to stable8
|
|
|
|
|
|
|
|
|
|
|
|
In line 161, "SQLite" has now the same capitalisation as in line 159.
|
|
|
|
|
|
enhance sqlite warning on admin page as well as during setup
|
|
|
|
|
|
|
|
Fix disabled files app
|
|
|
|
|
|
|
