- Mar 11, 2015
-
-
Jenkins for ownCloud authored
-
- Mar 10, 2015
-
-
Thomas Müller authored
Only rescan versions once in trashbin
-
Morris Jobke authored
-
Morris Jobke authored
update symphony components to 2.6.4
-
Robin Appelman authored
-
Lukas Reschke authored
Clean-up code and use proper exception types
-
Lukas Reschke authored
adding storage specific filename verification
-
Thomas Müller authored
Add support for 'child-src' directive
-
Jenkins for ownCloud authored
-
- Mar 09, 2015
-
-
Thomas Müller authored
Log errors and create 404 in network list when a css or js is missing
-
Thomas Müller authored
Verify CSRF token already in update.php and not the EventSource code
-
Morris Jobke authored
Fix size propagation over shared storage boundary
-
Morris Jobke authored
Etc timezones don't exist for .5 and .75 offsets
-
Vincent Petry authored
-
Joas Schilling authored
Check whether the file id is valid, before using it to delete the previews
-
Lukas Reschke authored
-
Joas Schilling authored
-
Thomas Müller authored
-
Thomas Müller authored
-
Thomas Müller authored
-
Lukas Reschke authored
-
Thomas Müller authored
-
Thomas Müller authored
-
Thomas Müller authored
-
Thomas Müller authored
-
Lukas Reschke authored
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 ;-)
-
Thomas Müller authored
proper filename for "require version.php"
-
Morris Jobke authored
LDAP: set up paged search even if limit is 0
-
Morris Jobke authored
-
Morris Jobke authored
Convert 'abcpassword' to 'abcpass' during setup
-
Jenkins for ownCloud authored
-
- Mar 08, 2015
-
-
Jenkins for ownCloud authored
-
- Mar 07, 2015
-
-
Robin McCorkell authored
This allows autoconfig files to use 'dbpassword' instead of 'dbpass', which is more consistent with config.php
-
Jenkins for ownCloud authored
-
- Mar 06, 2015
-
-
Morris Jobke authored
adjust list of errors, more compact and readable
-
Lukas Reschke authored
Fix totally broken AppStore code...
-
Thomas Müller authored
[sqlite] Use an atomic implementation on sqlite for insertIfNotExist() + use it in the file cache ...
-
Thomas Müller authored
-
Jan-Christoph Borchardt authored
-
Thomas Müller authored
-