tai42_app handle: the plugin depends on
tai42-contract and tai42-kit only and bans tai42_skeleton, and tai42_app raises on ANY member
access before bind() runs (bind() runs only inside start()), so a handle-based registration
would crash at plugin import in any process that imports the plugin before start() — the metrics
entrypoint never calls start() at all. So the plugin imports this module and calls
register_identity_provider at its own module import. The registry is plain module state: it
fills in ANY process that imports the plugin module, with no bind() anywhere.
The registry stores FACTORIES, not descriptors: an identity provider is a live object holding a
store/connection, so a plugin registers a callable that builds the provider from settings. The
application drives the staging lifecycle; this module stays epoch-free.
abort_staging
tai42_kit.access_control.registry.abort_staging
begin_staging
tai42_kit.access_control.registry.begin_staging
commit_staging
tai42_kit.access_control.registry.commit_staging
get_identity_provider_factory
tai42_kit.access_control.registry.get_identity_provider_factory
KeyError when unknown.
Parameters
get_identity_provider_factory_staged
tai42_kit.access_control.registry.get_identity_provider_factory_staged
iter_identity_provider_names_staged
tai42_kit.access_control.registry.iter_identity_provider_names_staged
register_identity_provider
tai42_kit.access_control.registry.register_identity_provider
tai42_kit.registry.same_factory) under a
name it already holds is a quiet no-op; a DIFFERENT factory under that name raises ValueError.
Parameters
reset_registry
tai42_kit.access_control.registry.reset_registry
tai42_kit.access_control.registry): accounts plugins never import the application package and
register at plain module import, before any app handle is usable. The application resolves and
ACTIVATES providers from its own configuration — registration alone activates nothing.
Two differences from the identity registry:
register_accounts_providerALSO registers the factory into the identity registry under the same name — an accounts provider IS the token answerer for its own sessions, so registering into only one registry would make sessions mintable but not validatable (or vice versa). One plugin call, both registries, loud duplicate errors from either. The application stages and commits the two registries together.- The registry is enumerable: the public login-methods aggregator asks EVERY registered accounts provider for its declared methods.
abort_staging
tai42_kit.accounts.registry.abort_staging
begin_staging
tai42_kit.accounts.registry.begin_staging
commit_staging
tai42_kit.accounts.registry.commit_staging
get_accounts_provider_factory
tai42_kit.accounts.registry.get_accounts_provider_factory
name in the COMMITTED generation; KeyError when unknown.
Parameters
iter_accounts_provider_factories
tai42_kit.accounts.registry.iter_accounts_provider_factories
iter_accounts_provider_factories_staged
tai42_kit.accounts.registry.iter_accounts_provider_factories_staged
register_accounts_provider
tai42_kit.accounts.registry.register_accounts_provider
ValueError, in either registry. The
accounts no-op returns before touching the identity registry, and the identity registry is written
only when this name is new here (a refusal there leaves this registry untouched), so the two never
drift.
Parameters
reset_registry
tai42_kit.accounts.registry.reset_registry

