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.
The one we ship may cause problems since Equifax is not included anymore (SHA-1 certs) are deprecated. We should just be consistent here and also use the certificate file which is used by the other calls in the library.
There are authentication backends such as Shibboleth that do send no Basic Auth credentials for DAV requests. This means that the ownCloud DAV backend would consider these requests coming from an untrusted source and require higher levels of security checks. (e.g. a CSRF check)
While an elegant solution would rely on authenticating via token (so that one can properly ensure that the request came indeed from a trusted client) this is a okay'ish workaround for this problem until we have something more reliable in the authentication code.
