Features

# Invitations

One of the main features of the verification service is to generate invitations that can be distributed in different ways. Invitations are in the form of an URL hence they can be distributed using email, instant messaging, QR code, etc. The domain flag is used to add a public address for the invitation link. An invitation has a default validity but that can be changed by using the validity flag.

# Storage

By default invitations storage is in-memory. It can be changed to an SQL back-end by setting the invitations-storage variable to either postgres or mysql. The connection string is in the engine://user:pass@address:5432/database format (for example postgres://postgres@127.0.0.1:5432/verification) and it is configured with the invitations-storage-sql flag. The database table is specified with the invitations-storage-relation flag.

./verification \
  --invitation-storage postgres \
  --invitation-storage-sql postgres://postgres@127.0.0.1:5432 \
  --invitation-storage-relation invitations
  ...

Table should be created in advance:

CREATE TABLE invitations (
  user_id text,
  code text,
  expiration integer,
  status text
);

Invitations also could be stored in Redis. Then the invitations-storage variable should be set to redis and configured by invitation-storage-redis, invitation-storage-redis-pass and invitation-storage-redis-db properties.

./verification \
  --invitation-storage redis \
  --invitation-storage-redis :6379 \
  --invitation-storage-redis-pass password \
  --invitation-storage-redis-db 0 \
  ...

The invitation feature has a boolean configuration variable invitation-storage-search that controls the search capabilities (filtering, sorting) of the invitations data.

# Email

The verification service supports sending invitations as an email. This is configured using enable-email-invitations, email-template, email-sender, smtp-user, smtp-password, smtp-port, and smtp-server. The email template is configured using the Golang templating engine.

# Email template context

• Sender
• Recipient
• InvitationLink

# Authentication

The authentication for the Administrative functions is implemented using OIDC. Any OpenID Connect Identity Provider can be used for admin authentication by using oidc-issuer, oidc-client-id, oidc-client-secret, and oidc-redirect-url flags.

# Storage

By default the session storage is in-memory. It can be changed to an SQL back-end by setting the session-storage variable to either postgres or mysql. The connection string is in the engine://user:pass@address:5432/database format and it is configured with the session-storage-sql flag.

./verification \
  --session-storage postgres \
  --session-storage-sql postgres://postgres@127.0.0.1:5432/verification
  ...

Table should be created in advance:

CREATE TABLE sessions (
  id varchar(36),
  user_id text,
  expiration int
);

Another option for the sessions is to be stored in Redis. To achieve this, the variable session-storage-redis should be set to redis and session-storage-redis, session-storage-redis-pass and session-storage-redis-db should be configured with the Redis configuration data respectively.

./verification \
  --session-storage redis \
  --session-storage-redis :6379 \
  --session-storage-redis_pass password \
  --session-storage-redis_db 0 \
  ...

# Authorization

Authorized users are configured using the authorized-users flag as a comma-separated values. Users are defined with the id type of the identity provider used for authentication.

./verification \
  --authorized-users admin1@example.com,admin2@example.com \
  ...