Storage

The Storage interface is designed to be a flexible and extensible abstraction for any storage backend used in the SDK. It provides a minimal contract that allows upper layers (like the license handler) to persist license data securely, regardless of the actual implementation (file system, database, remote service, etc.).

These setter and getter functions ensure that every Storage implementation uses a CryptoProvider to handle encryption and decryption of sensitive license data. This guarantees that all stored data—regardless of format or location—is encrypted with a consistent mechanism.

The SDK includes a built-in implementation of Storage called FileStorage, which persists encrypted data locally to disk. This interface extends Storage and defines all methods required to manage license files, guard files, and any encrypted metadata.

This interface provides all the required capabilities for securely storing and retrieving license and guard files using encryption. It can be used as-is or replaced with a custom storage implementation.

The CryptoProvider interface is responsible for encryption and decryption of sensitive data before it is saved or after it is loaded. It is designed to be pluggable, allowing you to implement your own encryption scheme if needed.

Any implementation of this interface must be able to securely encrypt and decrypt data using a key that can be set or retrieved. The SDK comes with a DefaultCryptoProvider implementation that uses AES encryption.

Both FileStorage and CryptoProvider come with default implementations:

You can use them directly when creating a LicenseHandler, or omit them entirely and let the SDK initialize the defaults automatically.

Example usage:

This setup allows you to override either the storage mechanism or the crypto logic without touching the SDK’s licensing logic.