-
Notifications
You must be signed in to change notification settings - Fork 9
Release 2.0.0
Support for replication, simpler API authentication and OAuth2 user authentication.
- Ported to jena 3.9.0. As consequence java8 is now required and text indexes must be migrated.
- 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.
- Support for OAuth 2.0 authentication.
N.B. The update to Jena brings with it an updated version of the Lucene text indexer which is not backward compatible with existing text indexes. To port an existing registry installation to this release you must delete the existing text index directory (default location is /var/opt/ldregistry/index). Then, once the registry is running under the new release, login as an administrator and rebuild the text index (Admin > Rebuild text index).
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.
#config.suppressPasswordLogin = true
config.passwordLoginOnly = true
config.suppressLinkView = true
config.showRegisterAsDatatable = true
#config.showClassDiagrams = true
config.registryName = Test Registry
config.showStatus = valid
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.
For existing installations create a user with ID "replication" then the manage users screen will offer and action to Grant Replication permissions to that user.
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.
You can use the OpenID Connect protocol for user authentication with an OAuth provider of your choice, or with multiple providers, by creating
configuration files in your config/oauth2 directory.
See the documentation on OAuth Configuration. Existing OAuth configurations must be replaced with the new structure and format.
On registry item pages, where a property has multiple, language-tagged values, those values will be displayed in a sub-table of the existing property-value table. The sub-table will show the language and corresponding text for each value, in a deterministic order.
Make sure that you have the latest version of registry-config-base in order to see changes to the UI.
The pages for registry items with "submitted" status will no longer be accessible to users who are not logged in, and will yield a 404 response instead. This is consistent with the way that those items are filtered out of the registry (list) views for those users. Users who are logged in will be able to view the items as usual.