sminnee/silverstripe-apikey

API Key management for Silverstripe CMS

1.0.0-beta4 2022-07-19 20:59 UTC

Requires

• silverstripe/framework: ^4.0
• silverstripe/graphql: ^1.0 || ^2.0 || ^3.0 || ^4.0
• silverstripe/vendor-plugin: ^1.0

Requires (Dev)

• phpunit/phpunit: ^5.7
• silverstripe/versioned: ^1.2

BSD-3-Clause

• Sam Minnee

README

This module provides a way of creating an managing API keys within SilverStripe. This can be useful for building RESTful and other APIs.

Requirements

• SilverStripe ^4 || ^5
• PHP 5.5+

Installation

composer require sminnee/silverstripe-apikey

How it works

• Extensions the the SecurityAdmin provide interfaces for seeing API keys, and generating new ones. API keys are allocated member-by-member.
• A RequestMiddleware will look for an API key header (default: X-API-Key) and if it is present, authenticate the user so that Member::currentUser() will return the corresponding member. This should be configured by non-GraphQL requests.
• A ApiKeyAuthenticator should be configured for GraphQL request and will return the authenticated member for GraphQL contexts to use, while not applying it to the CMS session.

Regular use

For regular module usage, use the RequestMiddleware class. The configuration to apply it is in this module's apikey.yml, but is commented out.

Copy the configuration and add it to your mysite/_config/apikey.yml file.

This will protect all of your frontend routes.

GraphQL

The GraphQL authenticator will work separately from the RequestMiddleware. If using this module for GraphQL, you will probably want to disable the RequestMiddleware. If you run both at the same time you will find that:

• Authentication exceptions are thrown outside of the GraphQL context (i.e. not wrapped in JSON output)
• Successful requests will register two "times used" each, since it's authenticated in two places

Limitations

• You can't limit the rights that the API key has to be more granular than "all rights of the given user".
• Keys can't be disabled, only deleted
• No support for storing encrypted ("read-once") keys

Status

This should be considered experimental for now, and used with care. It has not received a security audit.