Replaces the OC_Mail and phpmailer with SwiftMail allowing us to mock it properly.
Fixes the unit test execution on master on local machines and https://github.com/owncloud/core/issues/12014
Conflicts:
3rdparty
lib/private/server.php
lib/public/iservercontainer.php
tests/lib/mail.php
tests/settings/controller/mailsettingscontrollertest.php
Conflicts:
3rdparty
lib/private/mail.php
lib/private/server.php
lib/public/iservercontainer.php
settings/ajax/lostpassword.php
settings/application.php
- Added StorageConfig class to replace ugly arrays
- Implemented StorageService and StorageController for Global and User
storages
- Async status checking for storages (from Xenopathic)
- Auto-generate id for external storage configs (not the same as
storage_id)
- Refactor JS classes for external storage settings, this mostly
moves/encapsulated existing global event handlers into the
MountConfigListView class.
- Added some JS unit tests for the external storage UI
* Original avatarcontroller migrated to the appframework
* Added DataDisplayResponse that show data inline in the browser (used
to retrun the image)
* Removed some unneeded code
* Added unit tests for the avatarcontroller
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 ;-)