Feature Wiki
Tabs
ILIAS Cloud Folder / Cloud Interface
1 Requirements
File handling is one of the most important/most used features of ILIAS and we already have many ways to upload and handle files. This suggested feature would add a prominent way of file handling to ILIAS, namely: Cloud Folders.
A Cloud Folder is a repository object, which resembles the current folder of ILIAS and it contains only subfolders and files. After the creation of the Cloud Folder the user specifies to which cloud (e.g. DropBox, OwnCloud, SkyDrive, ...) and which folder in his cloud the Cloud Folder in ILIAS should be connected to and has to support his credentials if needed. After that the Cloud Folder will be a mirror image in ILIAS of the actual Cloud Folder with the advantage that the ILIAS user accessing the files can do so in the exact same way as he would with regular files in ILIAS and the user providing the files can manage his cloud folder fast and easy in his cloud.
Additionally a file upload will be available, allowing users to add files to the cloud as if he would add a file to ILIAS.
For a first iteration only an implementation of a DropBox interface is suggested with an additional plug-in interface, such that it will be fast to add further cloud services.
2 Status
- Scheduled for: ILIAS 4.4
- Funding: Funded by Universität Bern
- Development: Feature is to be developed by Universität Bern in association with sr.solutions.
3 Additional Information
- If you want to know more about this feature, its implementation or funding, please contact: Oskar Truffer <ot@studer-raimann.ch>
4 Discussion
JF 21 Jan 2013: We like and support the idea and schedule it as a plugin slot for 4.4. But we must clarify some technical details:
1. We are not sure if the suggestion to make drop box a core feature and other cloud services plugin-ins. We think all implementations should be plug-ins, since we do not want to create dependencies from other projects. But they all could be based on a common implementation (like suggested) which could be derived from the classes of the repository plugin slot. The cloud plugin slot extends the repository plugin slot and provides common features.
2. We should setup rules how the credentials of the services are used. E.g. passwords should be stored using (m)crypt() in the database. A key/salt could be stored in a separate file. This would make the external accounts safer (e.g. an SQL injection would not be enough). This handling could be also a part of the base implementation.
28 Feb 2013, Oskar Truffer, studer + raimann ag:
1. Using DropBox built in in the core is indeed not ideal. I would suggest to have a cloud plug-in interface without any plug-ins in the core. Another option would be to use the common open-source cloud service OwnCloud as a default plug-in, but this would need OwnCloud Server side plug-ins as well, which are in discussion but not yet planned/financed. Concerning the extension of the repository plugin slot: While every plug-in in the repository plug-in creates a new Module/Repository Object the cloud plug-in slot would only have a single "Cloud-Folder" repository Object in which the different plug-ins are distinguished, thus we don't suggest to extend the repository plugin slot. Furthermore if you want to write an additional plugin only very view methods have to be rewritten (connecting, file download/upload, authentication, browse) whereas the repository object is a very open construct.
2. Most API's of cloud services as many other services use OAuth or OAuth 2.0 as authentification mechanisms for external applications http://oauth.net/ (e.g. Google (Drive), DropBox, Microsoft SkyDrive, Twitter, ...). And I guess that any other cloud service uses a similar authentification mechanism. Thus there are no personal passwords to be saved anywhere and the authentification is highly standardized. For other cloud services as eg. OwnCloud, where the API and thus the authentification has to be implemented by the plugin developer, we would suggest an asymmetric PSK mechanism http://en.wikipedia.org/wiki/Public-key_cryptography.
Where the private keys for these authentifications lie is up to the system administrator and should be configurable (but they should not be within the www/ folder).
Alex Killing, 25 Nov 2013: The handling now is quite sub-standard. Especially the fact that module creation activation is separated from the installation of the activation of the plugins. This should have made clearer and be re-scheduled to the JF, as the original proposal of the JF did not have this flaw.
In general a JF discussion is missing here after the comments from Oskar. You must re-schedule these things on the agenda.
JF Nov 25 2013: We discussed the pros and cons of the current implementation and possible ways to make the administration of the activation easier. Unfortunately we did not find a solution that does not put component-related code into central classes, which is something we would like to avoid.
We also realized that Oskar has put the topic on the agenda, but that it has been "lost" somehow in the Feb/Mar/Apr Jour Fixes.
We accept the current implentation as it is and hope that the (de)activation of the feature won't be a too big usability issue.
Alex, 26 Nov 2013: I continued to think about the administration of the cloud module. Since it is now kind of an "empty" core module, it could get a separate "Cloud Settings" administration section as other modules have already. This section could basically include some information explaining the fact that plugins are needed and the module needs to be activated, linking to these two sections of the administration. So even if this section would not hold any settings, it would be an obvious point for an administrator to look for information.
5 Implementation
7 Oct 2013, Oskar Truffer, studer + raimann ag:
The implementation contains a new modul named "Cloud" which brings a new Plug-In Slot "CloudHook". As with the ILIAS core no plug-in is delivered, the Modul is not creatable by default. Thus, if you install a Cloud Plug-in in order to make it available in the repository, enable Cloud-Objects for creation in Administration » Repository » Modules. For the configuration of the different plug-ins see the plug-in descriptions. To install a plug-in copy the plug-in folder ./Customizing/global/plugins/Modules/Cloud/CloudHook/ and follow the instructions in the readme file.
Already developed, currently in the beta phase and available for ILIAS 4.4 is the Dropbox Plugin.
With the plug-in slot's interface remote filesystems can be integrated into ILIAS with an additional plug-in: E.g. Google Drive, Microsoft OneDrive, OwnCloud, Subversion Repository, FTP Server, any System with a WebDav Interface, etc. So if you are interested in developing your own cloud plug-in feel free to follow the Developement Guide or contact us.
Important to know is that the security of the plug-ins lies in the the plug-in developer's responsibility. The DropBox plug-in, for example, doesn't store your password in any way and the access is limited to a certain ILIAS folder within your Dropbox. But this might not be the case for some other interfaces. Thus, if you install a plug-in you should inform yourself about the security measurements of the plug-in.
Last edited: 17. Apr 2025, 15:01, Kunkel, Matthias [mkunkel]