Interface ChannelAccessValidator

All Superinterfaces:
AccessValidator
All Known Subinterfaces:
ApplicationCommandEventContext, ButtonEventContext, ChannelEventContext, ComponentEventContext, DeferrableInteractionEventContext, InteractionEventContext, MessageBasedContext, MessageCreateEventContext, MessageEventContext, MessageIncludedContext, ModalEventContext, RepliableContext, SlashCommandEventContext
All Known Implementing Classes:
AbstractChannelEventContext, AbstractRepliableContext
Functional Interface:
This is a functional interface and can therefore be used as the assignment target for a lambda expression or method reference.

@FunctionalInterface public interface ChannelAccessValidator extends AccessValidator
Validator that determines whether a caller has certain access rights in the context of a channel-based event.
Since:
1.0
Version:
1.0
API Note:
This type should usually not be manually created during handling; Rather, it should be obtained from the execution context in order to respect current configuration.
  • Method Summary

    Modifier and Type
    Method
    Description
    Determines whether the invoking user in the current execution context has access equivalent to the given group.
    default Mono<Boolean>
    Determines whether the invoking user in the current execution context has access equivalent to the given group.
    default Mono<Void>
    validate(Group group)
    Determines whether the invoking user in the current execution context has access equivalent to the given group.

    Methods inherited from interface dev.sympho.bot_utils.access.AccessValidator

    validate
  • Method Details

    • hasAccess

      @SideEffectFree Mono<Boolean> hasAccess(Group group)
      Determines whether the invoking user in the current execution context has access equivalent to the given group.

      Note that while the most straightforward implementation of this interface is to simply check if the caller belongs to the given group, implementations are allowed to add other conditions under which a user has equivalent permissions despite not belonging to the group (or conversely does not have permissions despite belonging to the group).

      Parameters:
      group - The group required for access.
      Returns:
      Whether the caller has access equivalent to the given group under the current execution context.
      Implementation Requirements:
      The returned mono should never be empty. However, client code is strongly encouraged to consider an empty result as equivalent to false to minimize the chance of a bug causing an invalid access to be allowed (fail-closed).
    • hasAccess

      default Mono<Boolean> hasAccess(GuildGroup group)
      Description copied from interface: AccessValidator
      Determines whether the invoking user in the current execution context has access equivalent to the given group.

      Note that while the most straightforward implementation of this interface is to simply check if the caller belongs to the given group, implementations are allowed to add other conditions under which a user has equivalent permissions despite not belonging to the group (or conversely does not have permissions despite belonging to the group).

      Specified by:
      hasAccess in interface AccessValidator
      Parameters:
      group - The group required for access.
      Returns:
      Whether the caller has access equivalent to the given group under the current execution context.
    • validate

      @SideEffectFree default Mono<Void> validate(Group group)
      Determines whether the invoking user in the current execution context has access equivalent to the given group.
      Parameters:
      group - The group required for access.
      Returns:
      A Mono that completes empty if the caller has access equivalent to the given group under the current execution context, or otherwise issues an error of type AccessException.
      API Note:
      This is a convenience method for scenarios where a failed check interrupts execution immediately.
      Implementation Requirements:
      If the access check returns an empty result (despite being a breach of the API), it is assumed to be a failed check as a safety measure (fails-closed).