#[non_exhaustive]pub struct RegistrationConfig {
pub registration_endpoint: Option<String>,
pub allowed_grant_types: Vec<GrantType>,
pub allowed_scopes: ScopeSet,
pub client_secret_ttl: Option<Duration>,
pub management_enabled: bool,
}Expand description
What dynamic registration is allowed to produce here. Held behind
crate::server::ServerConfig::registration, which is None (registration off) by default.
Every bound below is a CEILING on what an anonymous, or merely policy-approved, registrant can
obtain. The defaults are the narrow ones on purpose; see RegistrationConfig::new.
#[non_exhaustive]: this struct’s field set VARIES WITH CARGO FEATURES, so a host that writes a
full struct literal has a build that breaks the day anything in their dependency graph enables a
feature they did not ask for. Construct with new() and assign the fields you want. This is the
one attribute on this type that cannot be added after publication, because by then somebody’s
struct literal is in production.
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.registration_endpoint: Option<String>RFC 8414 section 2 registration_endpoint. None derives {issuer}/register.
allowed_grant_types: Vec<GrantType>The grants a registration may ask for. Anything outside this list is
invalid_client_metadata.
allowed_scopes: ScopeSetThe ceiling on a registration’s scope. A request outside it is invalid_client_metadata;
the default is EMPTY, so a host must say what a registrant may reach.
client_secret_ttl: Option<Duration>How long an issued client secret lives. None (the default) means it never expires, which
is what client_secret_expires_at: 0 says on the wire (RFC 7591 section 3.2.1).
management_enabled: boolWhether RFC 7592 read, update and delete are offered at all. true by default: a client
that can be created and never corrected or deleted leaves the host doing registration
lifecycle by hand.
Implementations§
Source§impl RegistrationConfig
impl RegistrationConfig
Sourcepub fn new() -> Self
pub fn new() -> Self
The narrow defaults: the authorization code grant with refresh, no scopes, management on.
client_credentials and the device grant are deliberately absent. A client_credentials
registration mints tokens with NO resource owner anywhere in the picture, so an open
registration endpoint that grants it is an open token endpoint; the device grant makes the
registrant able to allocate user codes, which RFC 8628 section 5.1 says are only adequate
in combination with rate limiting. Both are one line for a host to add, with its eyes open.
Trait Implementations§
Source§impl Clone for RegistrationConfig
impl Clone for RegistrationConfig
Source§fn clone(&self) -> RegistrationConfig
fn clone(&self) -> RegistrationConfig
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more