pub struct HttpProvider { /* private fields */ }Expand description
One external system holding data about a subject; built with
HttpProvider::new and registered with Privacy::provider.
Implementations§
Source§impl HttpProvider
impl HttpProvider
Sourcepub fn new(name: impl Into<String>, url: impl Into<String>) -> Self
pub fn new(name: impl Into<String>, url: impl Into<String>) -> Self
A provider named name, reached at url, whose /export,
/erase/plan and /erase/apply paths are appended to url.
Sourcepub fn secret_env(self, name: impl Into<String>) -> Self
pub fn secret_env(self, name: impl Into<String>) -> Self
The config/env variable holding this provider’s HMAC secret, read
through the config port at call time. None, missing or empty reports
not_configured — a call this module cannot sign is not one it sends.
Sourcepub fn timeout(self, timeout: Duration) -> Self
pub fn timeout(self, timeout: Duration) -> Self
The deadline for one call, clamped up to the port ceiling at send time.
Sourcepub fn max_response_bytes(self, max_response_bytes: usize) -> Self
pub fn max_response_bytes(self, max_response_bytes: usize) -> Self
The most bytes of a response this module will read, clamped to the
port ceiling. A larger response is invalid_response.
Sourcepub fn account(self) -> Self
pub fn account(self) -> Self
Marks this provider as the one holding the identity itself — the accounts table, the CRM’s contact record, the identity provider the others key on.
Why it must be erased last. Erasure identifies its subject by a
value (acct-1). Every provider after the account provider is reached
through that value, and the provider that holds the identity can
delete it. Called in registration order, a CRM holding only
account_id might be asked to erase after the accounts table is
already gone — and a row keyed on a subject the calling deployment no
longer holds an identifier for cannot be found, let alone erased. The
row survives and the erasure reports itself complete.
So marked providers sort after every unmarked one, in all three loops
(in_erasure_order): export, plan and apply. Within each group the
registration order is kept, so the answer is stable and a reader can
see the sequence a build produced rather than a sort’s opinion of it.
A build is expected to mark at most one provider this way — the account is one record however many systems mirror it — but nothing breaks if it marks several: they go last, in the order they were registered.