Download the PHP package sdkey/sdk without Composer
On this page you can find all versions of the php package sdkey/sdk. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Informations about the package sdk
sdkey/sdk
Official PHP client for SDKey license authentication.
Implements the sealed session protocol: Ed25519-verified handshake, HKDF session keys, and AES-256-GCM envelopes for validate, register, login, and upgrade. See PROTOCOL.md.
Version: 0.3.0 (Packagist / git tag v0.3.0)
Install
Requires PHP 8.1+ with ext-sodium, ext-openssl, ext-json, and ext-curl.
Quick start
Embed these values from the SDKey dashboard when you ship your app. appVersion must exactly match the application version configured in SDKey (clientVersion on session init); mismatch → APP_OUTDATED.
Sealed methods call init() automatically when no session exists. Sessions last ~15 minutes server-side; on SESSION_EXPIRED the client clears local state so the next call re-handshakes.
Client auth (sealed)
Register, login, and upgrade use the same crypto session as validate. Application binding and version gating come from session init — do not send appId / clientVersion in the auth body.
Breaking change (0.3.0): plaintext client-auth bodies no longer work when the API has CRYPTO_ENFORCE=true (400 CRYPTO_REQUIRED).
Message vs error fields
Per-app responseMessages may customize user-facing strings. The SDK returns those strings as-is.
| Surface | Success text field | Failure text field |
|---|---|---|
| Session init | (none) | error (via SdkeyError message + code) |
| Sealed validate | message (ValidateResult::$message) |
message |
| Sealed register / login / upgrade | (none on result) | message (via SdkeyError message + code) |
Sealed validate success (user-facing text in message):
Sealed validate failure (still message, not error):
Init failure (text in error):
Sealed auth failure (HTTP 200 + sealed body; text in plaintext message):
API
new SdkeyClient(...)
| Option | Type | Description |
|---|---|---|
apiBaseUrl |
string |
API origin (no trailing slash) |
appId |
string |
Application UUID |
appVersion |
string |
Exact app version → sent as clientVersion on session init |
appPublicKeyB64 |
string |
Raw Ed25519 public key (32 bytes), base64 |
httpPost |
callable |
Optional HTTP POST override (tests / custom transport): (string $url, array $body): array{0:int,1:array} |
Methods
init()— challenge handshake; verifies the signed hello; derives the AES session key; sendsclientVersionvalidate(licenseKey, hwid = null)— sealed validate; always decrypts then verifies the Ed25519 signature before trustingsuccess. Omithwidfor web (JSON key not sent)register(username, password, email?, licenseKey?, hwid?)— sealedPOST /api/v1/client/registerlogin(username, password, hwid?)— sealedPOST /api/v1/client/loginupgrade(username, licenseKey, hwid?)— sealedPOST /api/v1/client/upgrade(no password)getSession()/clearSession()— inspect or drop the local crypto session
Errors
Protocol / transport failures and init/auth denials throw SdkeyError with a code (server code when present) and message (init: server error; sealed auth: plaintext message):
INIT_FAILED · AUTH_FAILED · HELLO_SIGNATURE_INVALID · VALIDATE_RESPONSE_INVALID · RESPONSE_SIGNATURE_INVALID · SESSION_MISMATCH · CLOCK_SKEW · NETWORK · plus server codes such as APP_OUTDATED, TIER_NOT_HIGHER, …
License denials on sealed validate (banned, HWID mismatch, etc.) return a normal ValidateResult with success: false — they are not thrown.
This package does not include developer tooling / Bearer management APIs.
Security notes
- Never ship app private keys in a client.
- Do not skip signature verification — that is the anti-spoof binding.
- This package is open source; the SDKey server remains a separate product.
Development
License
MIT
All versions of sdk with dependencies
ext-json Version *
ext-openssl Version *
ext-sodium Version *
ext-curl Version *