Failure to prepare the storage during backend or auth mechanism
manipulation will throw an InsufficientDataForMeaningfulAnswerException,
which is propagated to StorageNotAvailableException in the filesystem
layer via the FailedStorage helper class.
When a storage is unavailable not due to failure, but due to
insufficient data being available, a special 'indeterminate' status is
returned to the configuration UI.
The following functions have been removed:
- addMountPoint()
- removeMountPoint()
- movePersonalMountPoint()
registerBackend() has been rewritten as a shim around BackendService,
allowing legacy code to interact with the new API seamlessly
addMountPoint() was already disconnected from all production code, so
this commit completes the job and removes the function itself, along
with disconnecting and removing related functions. Unit tests have
likewise been removed.
getAbsoluteMountPoints(), getSystemMountPoints() and
getPersonalMountPoints() have been rewritten to use the StoragesServices
Prior to this, the storage class name was stored in mount.json under the
"class" parameter, and the auth mechanism class name under the
"authMechanism" parameter. This decouples the class name from the
identifier used to retrieve the backend or auth mechanism.
Now, backends/auth mechanisms have a unique identifier, which is saved in
the "backend" or "authMechanism" parameter in mount.json respectively.
An identifier is considered unique for the object it references, but the
underlying class may change (e.g. files_external gets pulled into core
and namespaces are modified).
A backend can now specify generic authentication schemes that it
supports, instead of specifying the parameters for its authentication
method directly. This allows multiple authentication mechanisms to be
implemented for a single scheme, providing altered functionality.
This commit introduces the backend framework for this feature, and so at
this point the UI will be broken as the frontend does not specify the
required information.
Terminology:
- authentication scheme
Parameter interface for the authentication method. A backend
supporting the 'password' scheme accepts two parameters, 'user' and
'password'.
- authentication mechanism
Specific mechanism implementing a scheme. Basic mechanisms may
forward configuration options directly to the backend, more advanced
ones may lookup parameters or retrieve them from the session
New dropdown selector for external storage configurations to select the
authentication mechanism to be used.
Authentication mechanisms can have visibilities, just like backends.
The API was extended too to make it easier to add/remove visibilities.
In addition, the concept of 'allowed visibility' has been introduced, so
a backend/auth mechanism can force a maximum visibility level (e.g.
Local storage type) that cannot be overridden by configuration in the
web UI.
An authentication mechanism is a fully instantiated implementation. This
allows an implementation to have dependencies injected into it, e.g. an
\OCP\IDB for database operations.
When a StorageConfig is being prepared for mounting, the authentication
mechanism implementation has manipulateStorage() called,
which inserts the relevant authentication method options into the
storage ready for mounting.
Backends are registered to the BackendService through new data
structures:
Backends are concrete classes, deriving from
\OCA\Files_External\Lib\Backend\Backend. During construction, the
various configuration parameters of the Backend can be set, in a design
similar to Symfony Console.
DefinitionParameter stores a parameter configuration for an external
storage: name of parameter, human-readable name, type of parameter
(text, password, hidden, checkbox), flags (optional or not).
Storages in the StoragesController now get their parameters validated
server-side (fixes a TODO).
Storage status is saved in the database. Failed storages are rechecked every
10 minutes, while working storages are rechecked every request.
Using the files_external app will recheck all external storages when the
settings page is viewed, or whenever an external storage is saved.
str_replace for $user substitution was converting the data type of
mountOptions to string. This fix prevents this to happen by making sure
only strings are processed by substitution.
Also added a int conversion when reading the watcher policy
When reading in old mount.json files, they do not contain config ids.
Since these are needed to be able to use the UI and the new service
classes, these will be generated automatically.
The config grouping is based on a config hash.
The mount options are now passed to the UI and stored in a hidden field.
The ext storage controllers and services also know how to load/save them
from the legacy config.
- 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
Sometimes there are bugs that cause setupFS() to be called for
non-existing users. Instead of failing hard and breaking the instance,
this fix simply logs a warning.
Now the external storage correctly returns the mount points visible only
for the current user by using the method getAbsoluteMountPoints() which
is already filtered.
Since that call was missing the backend name which is important for the
UI, this one was added as well.
Each storage backend has a default priority, assigned to any system mounts
created in ownCloud. mount.json can be manually modified to change these
priorities.
The priority order is as follows:
* Personal
* User
* Group
* Global
Within each mount type, the mount with the highest priority is active.
The storage backend defaults were chosen to be the following:
* Local - 150
* Remote storage - 100
* SMB / CIFS with OC login - 90
An issue existed where `readData` used `OCP\User::getUser()` to get the user
for personal mount points, which worked in all situations apart from when a
personal mount point was used for sharing, so the return from `getUser()` is
not the user that owns the share. As such, any personal mount points would not
work correctly when shared.
`readData` and `writeData` have been changed from using a `$isPersonal`
boolean to using a `$user` string|null. `$isPersonal = false` can now be
written as `$user = NULL` (or left out in the case of `readData`), and
`$isPersonal = true` can be written as `$user = OCP\User::getUser()`.
Dependency messages now appear below the configuration options instead of above
Reworked dependency check method to support consolidated messages for multiple backends
Conflicts:
apps/files_external/lib/google.php
apps/files_external/lib/swift.php
apps/files_external/templates/settings.php
Added check for backend's checkDependencies method to OC_Mount_Config::getBackends() when backend is configured to have some instead of blindly calling it and crashing
Conflicts:
apps/files_external/lib/config.php
apps/files_external/lib/google.php
Moved dependency check to the individual backends instead of the config
Conflicts:
apps/files_external/appinfo/app.php
apps/files_external/lib/config.php
To check for shares, the code attempts to connect anonymously to the share.
In most cases this will fail with NT_STATUS_ACCESS_DENIED, so the regex array
used for parsing the output of smbclient in smb4php has been overridden to
treat such output as success.
The 'test' method for storage classes can now take a single parameter,
$isPersonal, which allows the storage to adjust the tests performed based on
if they are being configured as personal shares or as system shares.
Selecting 'SMB/CIFS Auto' in the mounts configuration allows an SMB/CIFS
mount to be configured that uses the credentials of the user logging in to
authenticate to the server.
Optionally, the username can be used as the share name, permitting home shares
to be dynamically mounted.
Merging of configurations is whenever the same config is available for
multiple users/groups, in which case the config is considered as a
single one by the UI, and shows multiple users/groups selected.
Fixed merging logic to make sure that class, mount point and options are
the same before merging them.
Fixed merging to work correctly when the same mount point path is used
for separate users and configs. These are now correctly shows in the UI
as separate entries.
The old password field is now preserved in the JSON structure to make
sure that the order is preserved.
This is a quick fix until the UI is fixed to not rely on the PHP array
key order.
- test config was written correctly (global and local)
- test that personal mount points can be added for allowed backends
- test that personal mount points cannot be added for disallowed backends
- added $skipTest flag to make it possible add mount points without
doing an actual check/connection (note: this is necessary because the
static class OC_Mount_Config cannot be mocked)
Robin McCorkell
Robin Appelman
Vincent Petry
Andreas Fischer
Robin McCorkell
Thomas Müller
Roeland Jago Douma
Jenkins for ownCloud
Morris Jobke
Jörn Friedrich Dreyer
Lukas Reschke
Volkan Gezer
Bjoern Schiessle
Lukas Reschke
Philipp Kapfer
Jan-Christoph Borchardt
Frank Karlitschek
Joas Schilling
Philipp Schmitt