% Generated by roxygen2: do not edit by hand
% Please edit documentation in R/board-lock.R
\name{locked-board}
\alias{locked-board}
\alias{is_board_locked}
\alias{is_board_locked.board}
\title{Locked boards}
\usage{
is_board_locked(board, ...)

\method{is_board_locked}{board}(board, ...)
}
\arguments{
\item{board}{A \code{board} object to dispatch on.}

\item{...}{Generic consistency.}
}
\value{
A logical flag.
}
\description{
A board can be deployed read-only by setting the \code{blockr.locked}
option (see \code{\link[=blockr_option]{blockr_option()}}). Locking is enforced server-side, not
by UI hiding: a forged \code{Shiny.setInputValue} bypasses any
\code{display: none} and fires the underlying observer, so the refusal has
to happen on the server. While locked, the two channels every
mutation funnels through -- the \code{board_update} lifecycle (see
\code{\link[=board_update]{board_update()}}) and \code{\link[=set_board_option_value]{set_board_option_value()}} -- refuse to apply
changes.
}
\details{
\code{is_board_locked()} reports whether a board is locked and dispatches
on the board, so a subclass can source the state however it likes
(for example gating an unlock behind an authenticated request). The
default \code{board} method reads the \code{blockr.locked} option, and
\code{blockr.dock}'s \code{is_dock_locked()} delegates here.
}
\section{Scope}{
 Locking guards against forged \emph{client input} -- a
browser that sets Shiny inputs but cannot run server-side R. It is
\strong{not} a defense against code executing in the session: blockr
evaluates arbitrary R, which can flip the option, rebind this generic
or mutate board state directly, and no in-process flag can prevent
that. A subclass method may raise the bar (e.g. an authenticated
unlock) but cannot close the gap on its own -- a hard boundary has to
live where the user's code does not run (a sandboxed evaluator, or an
ephemeral read-only deployment). Treat locking as a guard for
non-malicious users.
}

\examples{
is_board_locked(new_board())

}
