IDS Plugin

Contents

• Writing an IDS plugin
• Javadoc
• Release notes

Project Documentation

• Project Information
• Project Reports

When writing a plugin you have to provide methods that operate on your data: read it, check for its existence, write it, delete it and find information about it.

The call put(DsInfo dsInfo, String name, InputStream inputStream) in the MainStorageInterface is where you decide, using information about the data set that will hold the datafile and the name to be given to the datafile, a "location" value which is unique for your IDS instance and which can be used as an identifier to store and retrieve files. It will be some kind of path relative to the storage system you are using. The main danger is that someone will create a datafile object which has a location value which is not consistent with the policy you have defined in this "put" method. Such a location may cause data to be read that should be private or it could cause other people's data to be written or deleted.

The simplest way to protect against all such dangers is to enable the generation of a cryptographic hash in the ids.properties file. This results in the computation of a cryptographic hash which is appended to the location you return before storing the value in ICAT. The hash is based on the "id" of the datafile, the "location" value as seen by the plugin and a key known only to the IDS and which is defined in the ids.properties file. Each time the location from ICAT is passed to a plugin it is first check that the hash has the expected value and then the first part of the location field is passed to the plugin which will be guaranteed to be exactly what the original call to the put method returned. The plugin is not exposed to the hash at all. The value stored in icat is the location followed by the hash separated by a space. The hash value goes at the end to help with indexing in some cases.

If for some reason you don't want to follow the solution described above there are two approaches which are also safe but restrictive:

• You can make sure that only a few trusted people are authorized to create or update any datafile in ICAT.
• If you have a system without archive storage then only three plugin calls accept the location. In each case, in addition to the location the createId and the modId of the datafile are passed in so that the plugin can see if this was a trusted person.

If you don't want the safe solution and in addition you cannot work with the restrictions in the previous section then there are some things that you can do to help make things safer:

• You can check that the location does not try to get outside the storage area and that it conforms to your rules by matching the location against a suitable regular expression.
• You can make sure that write operations will not overwrite existing files (for main storage)
• You can use UUIDs in the location that the “put” call generates to make the value unguessable.
• You can add uniqueness contraints on the Datafile.location in the database, using the following SQL statement: ALTER TABLE DATAFILE ADD CONSTRAINT UNQ_DATAFILE_LOCATION UNIQUE (LOCATION) with a further similar statement if you wish to avoid duplicate Dataset.location values. Note however that since these constraints are only enforced at the database level and not known to ICAT, you will get an INTERNAL error "Unexpected DB response" rather then an OBJECT_ALREADY_EXISTS error in the case of a violation.