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
  • Option in UI to redirect logins to a separate registry instance

API Authentication

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

For example:

curl -i -H "Content-Type: text/turtle" --basic --user user:password --data-binary="@update.ttl" https://registry/register

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 = path/script.sh

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.

Login redirect

The generic config block in app.conf can be used to set a target server to which all login requests should be redirected.

config               = com.epimorphics.appbase.core.GenericConfig
config.loginMaster = https://environment.data.gov.uk/registry
registry.configExtensions = $config

This will set the given loginMaster to be both the target of the login form actions and the prefix for the the return address to be used after a successful login.

This allows the option to provide multiple registry instances behind a load balancer but designate one instance as a master for carrying out updates. An attempt to login to any of the replicas will be redirected to the master via the alias given in loginMaster. The master can in turn use the above replication support to replay the updates to all of the slave instances.

Clone this wiki locally