API Key management for SilverStripe
Installs: 1 976
Open Issues: 2
- silverstripe/framework: ^4.0
- silverstripe/graphql: ^1.0 || ^2.0 || ^3.0 || ^4.0
- silverstripe/vendor-plugin: ^1.0
- phpunit/phpunit: ^5.7
- silverstripe/versioned: ^1.2
This package is auto-updated.
Last update: 2023-05-27 03:13:32 UTC
This module provides a way of creating an managing API keys within SilverStripe. This can be useful for building RESTful and other APIs.
- SilverStripe ^4.0
- PHP 5.5+
composer require sminnee/silverstripe-apikey
How it works
- Extensions the the
SecurityAdminprovide interfaces for seeing API keys, and generating new ones. API keys are allocated member-by-member.
RequestMiddlewarewill 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.
ApiKeyAuthenticatorshould be configured for GraphQL request and will return the authenticated member for GraphQL contexts to use, while not applying it to the CMS session.
For regular module usage, use the
RequestMiddleware class. The configuration to apply it is in this module's
but is commented out.
Copy the configuration and add it to your
This will protect all of your frontend routes.
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
- 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
This should be considered experimental for now, and used with care. It has not received a security audit.