GuardKey: R6 class for the Key guard
In fireproof: Authentication and Authorization for 'fiery' Servers
GuardKey R Documentation
R6 class for the Key guard
Description
This class encapsulates the logic of the key based authentication scheme. See
guard_key() for more information
Super class
fireproof::Guard -> GuardKey
Active bindings
locationThe location of the secret in the request, either
"cookie" or "header"
open_apiAn OpenID compliant security scheme description
Methods
Public methods
Inherited methods
Method new()
Constructor for the class
Usage
GuardKey$new(key_name, validate, user_info = NULL, cookie = TRUE, name = NULL)
Arguments
key_nameThe name of the header or cookie to store the secret under
validateEither a single string with the secret
or a function that will be called with the arguments key, request, and
response and returns TRUE if its a valid secret (useful if you have
multiple or rotating secrets). If the function returns a character vector it
is considered to be authenticated and the return value will be understood as
scopes the user is granted. Make sure never to store secrets in plain text
and avoid checking them into version control.
user_infoA function to extract user information from the
key. It is called with a single argument: key which is the key
used for the successful authentication. The function should return a new
user_info list.
cookieBoolean. Should the secret be transmitted as a cookie. If
FALSE it is expected to be transmitted as a header.
nameThe name of the guard
Method check_request()
A function that validates an incoming request, returning
TRUE if it is valid and FALSE if not. It extracts the secret from
either the cookie or header based on the provided key_name and test it
using the provided validate function.
Usage
GuardKey$check_request(request, response, keys, ..., .datastore)
Arguments
requestThe request to validate as a Request
object
responseThe corresponding response to the request as a
Response object
keysA named list of path parameters from the path matching
...Ignored
.datastoreThe data storage from firesale
Method reject_response()
Upon rejection this guard sets the response status to 400
if it has not already been set by others. In contrast to some of the other
guards which implements proper HTTP schemes, this one doesn't set a
WWW-Authenticate header.
Usage
GuardKey$reject_response(response, scope, ..., .datastore)
Arguments
responseThe response object
scopeThe scope of the endpoint
...Ignored
.datastoreThe data storage from firesale
Method clone()
The objects of this class are cloneable with this method.
Usage
GuardKey$clone(deep = FALSE)
Arguments
deepWhether to make a deep clone.
Examples
# Create a guard of dubious quality
key <- GuardKey$new(
key = "my-key-location",
validate = "SHHH!!DONT_TELL_ANYONE"
)
fireproof documentation built on Dec. 17, 2025, 5:09 p.m.
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
| GuardKey | R Documentation |
R6 class for the Key guard
Description
This class encapsulates the logic of the key based authentication scheme. See
guard_key() for more information
Super class
fireproof::Guard -> GuardKey
Active bindings
locationThe location of the secret in the request, either
"cookie"or"header"open_apiAn OpenID compliant security scheme description
Methods
Public methods
Inherited methods
Method new()
Constructor for the class
Usage
GuardKey$new(key_name, validate, user_info = NULL, cookie = TRUE, name = NULL)
Arguments
key_nameThe name of the header or cookie to store the secret under
validateEither a single string with the secret or a function that will be called with the arguments
key,request, andresponseand returnsTRUEif its a valid secret (useful if you have multiple or rotating secrets). If the function returns a character vector it is considered to be authenticated and the return value will be understood as scopes the user is granted. Make sure never to store secrets in plain text and avoid checking them into version control.user_infoA function to extract user information from the key. It is called with a single argument:
keywhich is the key used for the successful authentication. The function should return a new user_info list.cookieBoolean. Should the secret be transmitted as a cookie. If
FALSEit is expected to be transmitted as a header.nameThe name of the guard
Method check_request()
A function that validates an incoming request, returning
TRUE if it is valid and FALSE if not. It extracts the secret from
either the cookie or header based on the provided key_name and test it
using the provided validate function.
Usage
GuardKey$check_request(request, response, keys, ..., .datastore)
Arguments
requestThe request to validate as a Request object
responseThe corresponding response to the request as a Response object
keysA named list of path parameters from the path matching
...Ignored
.datastoreThe data storage from firesale
Method reject_response()
Upon rejection this guard sets the response status to 400
if it has not already been set by others. In contrast to some of the other
guards which implements proper HTTP schemes, this one doesn't set a
WWW-Authenticate header.
Usage
GuardKey$reject_response(response, scope, ..., .datastore)
Arguments
responseThe response object
scopeThe scope of the endpoint
...Ignored
.datastoreThe data storage from firesale
Method clone()
The objects of this class are cloneable with this method.
Usage
GuardKey$clone(deep = FALSE)
Arguments
deepWhether to make a deep clone.
Examples
# Create a guard of dubious quality
key <- GuardKey$new(
key = "my-key-location",
validate = "SHHH!!DONT_TELL_ANYONE"
)
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
Embedding an R snippet on your website
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.