Skip to content

Split up Client and Server Callbacks with added type information. #35

@dequbed

Description

@dequbed

Splitting up the callback into a client & server variant makes sense as most users of this crate are either or, not both. This would also allow a better typing of the Callbacks as e.g. client callbacks don't need to implement validate, while server callbacks have to.

This would also allow a protocol implementation to require Callbacks with a given specialization. A server callback could thus statically type the additional data provided by SessionData and the type required for validate:

pub trait Specialization {
    /// Additional data provided by the protocol implementation in callbacks.
    type SessionData;

    /// Validation type returned on successful authentication
    type Validation;

    /// Error type returned specifically on failed authentication, can indicate type of failure.
    type ValidationError;
}

impl<S: Specialization> SessionData<S> {
    [...]
    fn protocol_session_data(&self) -> &S::SessionData { ... }
    [...]
}

pub trait ServerCallback<Specialization> {
    fn callback(&self, 
                session_data: &SessionData<Specialization::SessionData>,
                context: &Context,
                request: &mut Request
    ) -> Result<(), SessionError>;

    fn validate(&self, 
                session_data: &SessionData<Specialization>,
                context: &Context
    ) -> Result<Specialization::Validation, ValidationError<Specialization::ValidationError>>;
}

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions