AXIAM PHP SDK

AuthzRestClient
in package

FinalYes

REST authorization transport (FND-04, CONTRACT.md §1): `checkAccess()`/`can()`/ `batchCheck()` over `POST /api/v1/authz/check[/batch]` — the ALWAYS-available authz path (D-03). Reuses the caller-supplied Guzzle client (the same instance {@see \Axiam\Sdk\Session} wires with {@see AuthMiddleware}/{@see RefreshMiddleware} on its `HandlerStack`), so `Authorization`/`X-Tenant-ID`/`X-CSRF-Token` header injection and the single-flight refresh-on-401 behavior (D-06) apply to authz calls exactly as they do to every other REST call — this class never re-implements any of that.

Wire field names match crates/axiam-api-rest/src/handlers/authz_check.rs exactly: action, resource_id (camelCase resourceId on the PHP call surface, snake_case on the wire), optional scope. tenant_id is never sent in the body — the server derives it from the verified JWT (SEC-003). subject_id is likewise omitted by default (the server falls back to deriving the subject from the same verified JWT, i.e. whichever session's Bearer token is attached to the request) — but CONTRACT.md §11.2.2 (declarative authorization helpers) requires an explicit, additive subject_id override: AccessEnforcer calls a shared AXIAM client on behalf of the REQUEST's authenticated end user, which is a different identity than whatever session the shared client itself is authenticated as (typically a service account) — omitting subject_id in that scenario would silently check the service account's permissions instead of the end user's. See self::checkAccess()'s $subjectId parameter.

Table of Contents

Methods

__construct()  : mixed
batchCheck()  : array<int, bool>
`batchCheck` (CONTRACT.md §1): `POST /api/v1/authz/check/batch`. `$checks` is a list of `[action, resourceId, scope?]` tuples; the returned list of `allowed` booleans preserves input order exactly, matching `BatchCheckAccessResponse::results` on the server (same order/length guarantee).
can()  : bool
`can` (CONTRACT.md §1): the ergonomic browser/UI-scenario alias for {@see self::checkAccess()} — same endpoint, same semantics (§1 note: "`can` is an alias for `check_access`").
checkAccess()  : bool
`checkAccess` (CONTRACT.md §1). `POST /api/v1/authz/check`. Returns the decoded `allowed` boolean; non-2xx responses are translated via {@see ErrorMapper} (403 -> `AuthzError`, 401 -> `AuthError`, everything else -> `NetworkError`).

Methods

__construct()

public __construct(Client $http) : mixed
Parameters
$http : Client

batchCheck()

`batchCheck` (CONTRACT.md §1): `POST /api/v1/authz/check/batch`. `$checks` is a list of `[action, resourceId, scope?]` tuples; the returned list of `allowed` booleans preserves input order exactly, matching `BatchCheckAccessResponse::results` on the server (same order/length guarantee).

public batchCheck(array<int, array{action: string, resourceId: string, scope?: string|null}> $checks) : array<int, bool>
Parameters
$checks : array<int, array{action: string, resourceId: string, scope?: string|null}>
Return values
array<int, bool>

can()

`can` (CONTRACT.md §1): the ergonomic browser/UI-scenario alias for {@see self::checkAccess()} — same endpoint, same semantics (§1 note: "`can` is an alias for `check_access`").

public can(string $resource, string $action) : bool
Parameters
$resource : string
$action : string
Return values
bool

checkAccess()

`checkAccess` (CONTRACT.md §1). `POST /api/v1/authz/check`. Returns the decoded `allowed` boolean; non-2xx responses are translated via {@see ErrorMapper} (403 -> `AuthzError`, 401 -> `AuthError`, everything else -> `NetworkError`).

public checkAccess(string $action, string $resourceId[, string|null $scope = null ][, string|null $subjectId = null ]) : bool
Parameters
$action : string
$resourceId : string
$scope : string|null = null
$subjectId : string|null = null

Additive, optional (CONTRACT.md §11.2.2): when given, sent on the wire as subject_id so the server evaluates the check for THIS subject rather than whichever identity the calling client's own Bearer token represents. null (the default) preserves the pre-§11 behavior exactly — no subject_id field is sent, and the server derives the subject from the verified JWT as before.

Return values
bool
On this page

Search results