Plugin Configuration Options

The functionality of FROST-Server can be expanded using plugins. Which plugins are loaded is controlled by two parameters:

• plugins.providedPlugins:
  A comma-separated list of class names, listing the plugins provided with FROST by default. Normally there should be no need to change this.
• plugins.plugins:
  A comma-separated list of class names, listing additional plugins to load.

Besides these configuration options telling FROST which plugins exist, each plugin usually has a separate option that controls whether the plugin is active or not.

See the CoreModel and CoreModelV2 sections below.

Data Model Plugins

These plugins implement the data models are provided with FROST-Server by default.

SensorThings V1.1 & v2.0

The SensorThings API and its datamodel are plugins in FROST. There are separate plugins for the v1.1 data model, the v2.0 data model, the v1.1 API and the v2.0 API.

• plugins.coreModel.enable: Since 2.0.0
  Toggle indicating the version 1.1 data model plugin should be enabled. Default: true.
• plugins.coreService.enable: Since 2.0.0
  Toggle indicating the version 1.1 API plugin should be enabled. Default: true.
• plugins.coreModelV2.enable: Since 2.8.0
  Toggle indicating the version 2.0 data model plugin should be enabled. Default: false.
• plugins.coreServiceV2.enable: Since 2.8.0
  Toggle indicating the version 2.0 API plugin should be enabled. Default: false.

Not that both API plugins can be enabled at the same time, but only one of the data model plugins. The V2 data model plugin requires the ModelLoader plugin.

Actuation

The actuation plugin implements the standard OGC SensorThings API - Part 2: Actuation. It adds the entity types described in this specification. This plugin requires either the CoreModel or the coreModelV2 plugin. If the coreModelV2 plugin is active, the actuation plugin will use the Actuation extension from the draft OGC 24-046, OGC SensorThings API 2.0 Extensions.

• plugins.actuation.enable:
  Toggle indicating the Actuation plugin should be enabled. Default: false.
• plugins.actuation.idType.actuator:
  The type of the primary key column of the Actuator table. Defaults to the value of plugins.coreModel.idType.
• plugins.actuation.idType.task:
  The type of the primary key column of the Task table. Defaults to the value of plugins.coreModel.idType.
• plugins.actuation.idType.taskingCapability:
  The type of the primary key column of the TaskingCapability table. Defaults to the value of plugins.coreModel.idType.

CoreModel

The Core Model plugin implements the data model of the standard OGC SensorThings API - Part 1: Sensing. It adds the entity types described in this specification and their behaviour.

• plugins.coreModel.enable:
  Toggle indicating the CoreModel plugin should be enabled. Default: true.
• plugins.coreModel.editableDsProperties:
  Toggle indicating the server-generated properties of (Multi)Datastreams can be edited. Default: false.
• plugins.coreModel.idType:
  The default type of the primary key columns, can be overruled on a per-table basis:
  • LONG:
    Default value, using Long values for entity ids, generated in sequence.
  • STRING:
    Using String values for entity ids, with new values generated using uuid_generate_v1mc().
    When using this implementation, make sure you execute the command CREATE EXTENSION "uuid-ossp"; on the database.
  • UUID:
    Using uuid values for entity ids, with new values generated using uuid_generate_v1mc().
    When using this implementation, make sure you execute the command CREATE EXTENSION "uuid-ossp"; on the database.
• plugins.coreModel.idType.datastream:
  The type of the primary key column of the Datastream table. Defaults to the value of plugins.coreModel.idType.
• plugins.coreModel.idType.feature:
  The type of the primary key column of the Features table. Defaults to the value of plugins.coreModel.idType.
• plugins.coreModel.idType.historicalLocation:
  The type of the primary key column of the HistoricalLocation table. Defaults to the value of plugins.coreModel.idType.
• plugins.coreModel.idType.location:
  The type of the primary key column of the Location table. Defaults to the value of plugins.coreModel.idType.
• plugins.coreModel.idType.observedProperty:
  The type of the primary key column of the ObservedProperty table. Defaults to the value of plugins.coreModel.idType.
• plugins.coreModel.idType.observation:
  The type of the primary key column of the Observation table. Defaults to the value of plugins.coreModel.idType.
• plugins.coreModel.idType.sensor:
  The type of the primary key column of the Sensor table. Defaults to the value of plugins.coreModel.idType.
• plugins.coreModel.idType.thing:
  The type of the primary key column of the Thing table. Defaults to the value of plugins.coreModel.idType.

CoreModelV2

The Core Model plugin implements the data model of the standard OGC SensorThings API 2.0. It adds the entity types described in this specification and their behaviour. This plugin inherits the plugins.modelLoader.idType.<EntityTypeName>: settings from the ModelLoader plugin.

• plugins.coreModelV2.enable: Since 2.8.0
  Toggle indicating the version 2.0 data model plugin should be enabled. Default: false.
• plugins.coreServiceV2.enable: Since 2.8.0
  Toggle indicating the version 2.0 API plugin should be enabled. Default: false.

MultiDatastream

The MultiDatastream plugin implements the MultiDatastream extendion of the OGC SensorThings API standard. This plugin requires the CoreModel plugin.

• plugins.multiDatastream.enable:
  Toggle indicating the MultiDatastream plugin should be enabled. Default: false.
• plugins.multiDatastream.idType.multiDatastream:
  The type of the primary key column of the Datastream table. Defaults to the value of plugins.coreModel.idType.

ModelLoader

The ModelLoader plugin can load data models and security definitions from files. The models loaded by this plugin may require other data model plugins. Data model files and security definition files can be edited with the ModelEditor. Data model files can be initially generated from an existing database using the ModelExtractor.

Using Security Wrappers and Security Validators it is possible define in minute detail what a user is allowed to read, create, update and delete. The rules for this can take into account what the relations are that each Entity has with other Entities, as deep as required. Setting this up correctly is not trivial and a mistake in the authorisation may inadvertently open your data for reading or even editing. Therefore, we strongly recommend you contact us for support if your use case requires fine-grained authorisation.

• plugins.modelLoader.enable: Since 2.0.0
  Toggle indicating the ModelLoader plugin should be enabled. Default: false.
• plugins.modelLoader.idType.<EntityTypeName>:
  The type of the primary key column of the table for the given Entity Type. Defaults to the value of plugins.coreModel.idType.
• plugins.modelLoader.modelPath: Since 2.0.0
  The file path where model definition files are located. This path is prepended to each entry in plugins.modelLoader.modelFiles.
• plugins.modelLoader.modelFiles: Since 2.0.0
  A comma-separated list of model files to load. Each entry is prefixed with plugins.modelLoader.modelPath.
• plugins.modelLoader.liquibasePath: Since 2.0.0
  The file path where Liquibase (database definition) files are located. This path is prepended to each entry in plugins.modelLoader.liquibaseFiles.
• plugins.modelLoader.liquibaseFiles: Since 2.0.0
  A comma-separated list of Liquibase (database definition) files to load. Each entry is prefixed with plugins.modelLoader.liquibasePath.
• plugins.modelLoader.securityPath: Since 2.2.0
  The file path where security definition files are located. This path is prepended to each entry in plugins.modelLoader.securityFiles.
• plugins.modelLoader.securityFiles: Since 2.2.0
  A comma-separated list of security files to load. Each entry is prefixed with plugins.modelLoader.securityPath.
• plugins.modelLoader.metadataData: Since 2.3.2
  A json-string containing extra data to add to the serverSettings object on the landing page. The added data is merged into the existing data.
• plugins.modelLoader.metadataPath: Since 2.3.2
  The file path where extra metadata files are located. This path is prepended to each entry in plugins.modelLoader.metadataFiles.
• plugins.modelLoader.metadataFiles: Since 2.3.2
  A comma-separated list of meta data files to load. Each entry is prefixed with plugins.modelLoader.metadataPath. Each file is loaded and its JSON-content is merged into the serverSettings object on the ROOT-URL.

Projects

The Projects plugin extends the standard data model with a Project class and User/Role classes that allow fine-grained access control. This plugin requires the ModelLoader and either CoreModel or CoreModelV2 plugins.

• plugins.projects.enable:
  Toggle indicating the Projects plugin should be enabled. Default: false.
• plugins.projects.enableDefaultRules:
  Toggle indicating the default fine-grained access control rules should be activated. Default: true.
• plugins.projects.updateFeatureWithLocation: Since 2.5.4
  Toggle indicating that generated FeaturesOfInterest should be updated when the restricted flag, or the Projects of a Location are updated. Default: false.

Settings for the UserRoleDecoder class UserRoleDecoderDflt

When auth.registerUserLocally is used in the KeyCloak Auth Provider, the class de.fraunhofer.iosb.ilt.frostserver.plugin.projects.ProjectRoleDecoder can be used to register users and user-roles in the relevant tables.

• auth.userTable: Since 2.4.0
  The table to register users in. Default value: USERS
• auth.usernameColumn: Since 2.4.0
  The column for the user name. Default value: USER_NAME
• auth.prd.insertQuery: Since 2.4.0
  Query used to register a role for a user. The query parameters are the username and two match-groups from the roleRegex. Default value: insert into "USER_PROJECT_ROLE" ("USER_NAME", "PROJECT_ID", "ROLE_NAME") VALUES (?,(select "ID" from "PROJECTS" where "NAME"=?),?)
• auth.prd.roleRegex: Since 2.4.0
  The regular expression used to split a role from KeyCloak into a project name and a local role name. Default value: ^([a-zA-Z0-9 ]+)__([a-zA-Z0-9]+)$
• auth.prd.cleanupQuery: Since 2.4.0
  The query used to remove all old roles for a user, before inserting the current roles. Default value: delete from \"USER_PROJECT_ROLE\" where \"USER_NAME\" = ?

Response Format Plugins

These plugins enable various response formats.

DataArray

The DataArray plugin implements the SensorThings Data Array Extension as described in the SensorThings API standard.

• plugins.dataArray.enable:
  Toggle indicating the ResultFormat dataArray should be enabled. Default: true.

CSV Result Format

The CSV plugin implements a CSV result formatter, enabling CSV output as described in: CSV-ResultFormat

• plugins.csv.enable:
  Toggle indicating the ResultFormat CSV should be enabled. Default: true.

GeoJSON Result Format

The GeoJSON plugin implements a GeoJSON result formatter, enabling GeoJSON output as described in: GeoJSON-ResultFormat

• plugins.geojson.enable:
  Toggle indicating the ResultFormat GeoJSON should be enabled. Default: true.

Other Plugins

These plugins enable various other behaviours.

BatchProcessing

The BatchProcessing plugin implements the Batch Requests extension as described in the SensorThings API standard.

• plugins.batchProcessing.enable:
  Toggle indicating the BatchProcessing plugin should be enabled. Default: true.
• plugins.batchProcessing.streaming: Since 2.4.0
  Toggle indicating the BatchProcessing plugin can start sending the response before the batch is fully received. Turn this off if you are behind a proxy that does not support this (like nginx). Default: true.

OData

The OData plugin makes the data in your FROST-Server available as OData 4.0 and 4.01 API. The endpoint for these are on [service root URL]/ODATA_4.0/ and [service root URL]/ODATA_4.01/.

• plugins.odata.enable:
  Toggle indicating the OData plugin should be enabled. Default: false.

OpenAPI

The OpenAPI plugin makes an OpenAPI description of the SensorThings service available at the /v1.x/api path. This description is still experimental, and probably incomplete. If you use it and have experience with OpenAPI, we welcome feedback!

• plugins.openApi.enable:
  Toggle indicating the OpenAPI plugin should be enabled. Default: false.