The login process needs to be completed before we can safely create
the users home folder. For example we need to give encryption a chance
to initialize the users encryption keys in order to copy the skeleton
files correctly
When running with a user database backend on large installations the
cache can grow to significant sizes. This can be especially problematic
when running big cron/repair jobs.
The previous logic did not necessarily trigger in every case. This logic is more error-resistant, the autoload_classmap.php file has a guaranteed different hash on 9.0.0, 9.0.1 and 9.0.2
Fixes https://github.com/owncloud/updater/issues/342
jquery.fileupload offers the [`pastezone`](https://github.com/blueimp/jQuery-File-Upload/wiki/Options#pastezone) functionality. This functionality is enabled by default and if somebody copy-pastes something into Chrome it will automatically trigger an upload of the content to any configured jquery.fileupload element embedded in the JS.
This implementation triggers some problems:
1. The pastezone is defined globally by default (🙈). So if there are multiple fileupload's on a page (such as in the personal settings) then stuff is going to be uploaded to all embedded uploads.
2. Our server code is not able to parse the data. For example for uploads in the files app we expect a file name which is not specified => Just an error is thrown. You can reproduce this by taking a file into your clipboard and in Chrome then pressing <kbd>CTRL + V</kbd>.
3. When copy-pasting some string from MS Office on the personal page a temporary avatar with said content is created.
Considering that this is anyways was never working at all and causes bugs I've set the `pastezone` to `null`. This mens that upload via copy and paste will be disabled.
Lesson learned: Third-party JS libraries can have some weird details.
* getFromCache is wrapped in isCached
* inbetween the two calls the cache entry hits it's TTL
* getFromCache returns null
* this fix only checkes if the returned value is null and
return only non-null values
For one, it solves potential conflicts when using the resource. For the
other, one on the login check (the only place where a clone happens
currently) we do not need to rebind after confirming the user's login
was successful.
In theory, if your instance ever creates more jobs then your system cron can
handle, the default background jobs get never executed anymore. Because
everytime when the joblist returns the next job it looks for the next ID,
however there is always a new next ID, so it will never wrap back to execute
the low IDs. But when we change the sort order to be DESC, we make sure that
these low IDs are always executed, before the system jumps back up to
execute the new IDs.
In some scenarios initMountPoints is called with an empty user, and
also there is no user in the session.
In such cases, it is unsafe to let the code move on with an empty user.
Joas Schilling
Björn Schießle
Thomas Müller
Roeland Jago Douma
C Montero-Luque
C. Montero Luque
Thomas Müller
Lukas Reschke
Robin Appelman
Victor Dubiniuk
Arthur Schiwon
Daniel Jagszent
Morris Jobke
Vincent Petry