Skip to content

Release 2.0.0

Jump to bottom
Dave Reynolds edited this page Nov 24, 2016 · 8 revisions

Support for replication and simpler API authentication

Changes

  • Ported to jena 3.1.1. As consequence java8 is now required.
  • Allows http(s) basic authentication on API calls using registered password.
  • Replayable logging of updates with support for replication

API Authentication

Non-GET API calls can now be authenticated with a simple username/password pair over http Basic authentication.

We strongly recommend only using this over https but that recommendation is not enforced since there are cases where updates are restricted to private networks.

This is configured in the shiro.ini file by installing a new Shiro filter that accepts all GET requests and challenges all other requests for Basic authentication. If the session is already logged in by form-based authentication or OAuth2 then that is used and there is no additional Basic authentication challenge.

Replication

It is now possible to configure logging of all update actions in a replayable format. This replaces the old payload logging (which only did half of the required job).

This is configured in app.conf through:

requestLogger        = com.epimorphics.registry.message.GenericRequestLogger
requestLogger.logDir = /var/opt/ldregistry/logstore
# requestLogger.notificationScript = 

registry.requestLogger = $requestLogger

Other request logger implementations could be injected. The generic implementation will log each successful update to a separate file in the configured log directory. The final name carries date (and operation) information. The file content is a Turtle syntax payload with an initial comment line containing the operation, target URL and query parameters. If there is no payload then the file will only contain the comment line defining the operation.

If the notificationScript is set then it is assumed to be a system command or shell script which will take the name of the generated log file and carry out some action. This might include copying the log file to separate resilient storage and/or sending the file to separate read-only slave copies of the registry.

A log file can be replayed (or played into a slave copy) by POSTing it to the endpoint /system/replay on the target registry.

This requires suitable credentials, which might be provided using the above Basic auth support. For example a replication user could be created by placing the following in the user.ini bootstrap file.

# user replication "Replication user" password
# replication Replication:/

The permission Replication is an alias for Register,Update,StatusUpdate,Force,RealDelete.

Clone this wiki locally