Appendix M. SavaPage Plug-ins

Table of Contents

M.1. Web API Callback Plug-in
M.1.1. Payment Gateway Plug-in
M.2. OAuth Client Plug-in
M.3. Mail Print IMAP OAuth Plug-in
M.4. Notification Plug-in
M.5. IPP Routing Plug-in
M.6. User Source Plug-ins
M.6.1. User Synchronization Plug-in
M.6.2. User Authentication Plug-in

A plug-in (aka extension) is a software component that adds a specific feature to SavaPage. Plug-ins have a well-defined interface so partner developers can easily create isolated components that extend the application with new features. Extension interfaces are defined in the savapage-ext project.

A plug-in is installed by copying its property file in /opt/savapage/server/ext and its jar files in the /opt/savapage/server/ext/lib directory. For example, the Mollie Payment Plug-in is installed with these two files:

/opt/savapage/server/ext/savapage-ext-mollie.properties
/opt/savapage/server/ext/lib/savapage-ext-mollie-<version>.jar

Important

Since property files contain sensitive data make sure they are protected by executing commands like:

sudo chown savapage:savapage savapage-ext-mollie.properties
sudo chmod 600 savapage-ext-mollie.properties

M.1. Web API Callback Plug-in

The Web API Callback method is used by many third-party providers who offer their services via HTTP. SavaPage supports this method with the /callback URL path. However, URL protocol and authority for the callback needs to be configured. Configuration is done by using the Config Editor of the Admin Web App. The following configuration property is available:

Configuration propertyDescription

ext.webapi.callback.url-base

The publicly accessible base URL, i.e. protocol://authority without the path, of the Web API callback interface (no trailing slash).

When SavaPage is implemented as intranet application to be accessed with a local URL, take care to configure proper port forwarding of the public base URL to the local SavaPage server host name or IP address in your router or firewall.

Important: use https protocol, and make sure the SSL Certificate for public access is valid, i.e. not self-signed. When the certificate is invalid, a third-party service provider might not be able to deliver call-back messages.

Table M.1. Web API Callback Configuration Property


M.1.1. Payment Gateway Plug-in

The Payment Gateway Plug-in is based on the Web API Callback Plug-in and uses the /callback/payment URL path. The following configuration property can be set by using the Config Editor of the Admin Web App.

Configuration propertyDescription

ext.webapi.redirect.url-webapp-user

The User Web App URL used by the Web API to redirect to after a remote Web App dialog is finished.

Configuration is optional. SavaPage uses the local URL from which the remote excursion started as default.

Table M.2. Payment Gateway Configuration Property


Payment Gateway events are persisted in the rotating log file:

/opt/savapage/server/logs/paymentgateway.log

This file has a tab separated value (TSV) format for easy import and manipulation into spreadsheet programs.

M.1.1.1. Generic Payment Plug-in

A Generic Payment Plug-in implements several payment methods behind a single Web API. Only one generic plug-in can be active. See Section 3.10.5, “Financial”, Section 3.10.8, “Transfer Money” and Chapter 8, Payment Web App.

M.1.1.1.1. Mollie Payment Plug-in

Mollie is a Dutch payment provider that offers a single Web API for various payment methods, including:

  • Creditcard

  • PayPal

  • paysafecard

  • SOFORT Banking (Europe)

  • SEPA bank transfers (Europe)

  • Bancontact/Mister Cash (Belgium)

  • Belfius Direct Net (Belgium)

  • IDEAL (Netherlands).

Mollie supports the European Economic Area and Switzerland and accepts EUR payments only.

See the README.md of the savapage-ext-mollie project for more information.

Note

The Mollie Payment Plug-in is shipped with the SavaPage install binary.

M.1.1.1.2. Generic Payment Pitfalls

Callback messages for generic payments return the identity of the user that started the payment in the Transfer Money dialog. So, when a payment is acknowledged, we can easily add the amount paid to the user's balance. In some very unlikely cases a user might not be found. For example, when a database export is restored or a user was deleted, all in the short lifecycle of a payment transaction.

In the rare case a user is not found, a warning message containing the user and transaction identification are written to the Application Log. With this information the user balance can be updated manually, after the user has been added again, either in the Admin WebApp or with a Server Command.