Documentation ¶
Index ¶
- Variables
- func FalconClient(ctx context.Context, r Request) (*client.CrowdStrikeAPISpecification, error)
- func Fn() struct{ ... }
- func JSON(v any) json.Marshaler
- func RegisterConfigLoader(loaderType string, cr ConfigLoader)
- func RegisterRunner(runnerType string, r Runner)
- func Run[T Cfg](ctx context.Context, newHandlerFn func(cfg T) Handler)
- type APIError
- type Cfg
- type ConfigLoader
- type Handler
- type HandlerFn
- type Mux
- type Request
- type RequestOf
- type Response
- type Runner
- type SkipCfg
Constants ¶
This section is empty.
Variables ¶
var (
ErrCfgNotFound = errors.New("no config provided")
)
Functions ¶
func FalconClient ¶
FalconClient returns a new instance of the GoFalcon client. If the client cannot be created or if there is no access token in the request, an error is returned.
func RegisterConfigLoader ¶ added in v0.4.0
func RegisterConfigLoader(loaderType string, cr ConfigLoader)
func RegisterRunner ¶ added in v0.4.0
RegisterRunner registers a runner.
Types ¶
type Cfg ¶ added in v0.4.0
type Cfg interface {
OK() error
}
Cfg marks the configuration type parameter. Any config type must have a validation method, OK, defined on it.
type ConfigLoader ¶ added in v0.4.0
type Handler ¶
Handler provides a handler for our incoming request.
TODO(berg): I'm a little confused why we have a response, with APIErrors, and a go type error being returned in the legacy sdks. This creates multiple ways to do the same thing. I'd be confused, as I am now I suppose, with what goes where. If we remove the error from the return tuple, the only place for errors now is in the Response type. I think this makes good sense. Lets not create a failure condition from something that could be in user space.
func ErrHandler ¶ added in v0.4.0
func ErrHandler(errs ...APIError) Handler
ErrHandler creates a new handler to resopnd with only errors.
func HandleFnOf ¶ added in v0.4.0
HandleFnOf provides a means to translate the incoming requests to the destination body type. This normalizes the sad path and provides the caller with a zero fuss request to work with. Reducing json boilerplate for what is essentially the same operation on different types.
TODO(berg): name could be HandlerOf perhaps?
type Request ¶
type Request RequestOf[json.RawMessage]
Request a word for Request. We can treat it as an internal impl details, and provide the user an http.Request, built from this internal impl. They can then build up the usual http.ServeHTTP, the same as they are likely accustomed too. We too can take advantage of this and add middleware,etc to the runner as needed. When testing locally, they just use curl, and they provide it the way they are use too. For our lambda impl, we convert it to the expected request body the http server expects, then its treated the same as our standard impl.
type RequestOf ¶ added in v0.4.0
type RequestOf[T any] struct { Body T // TODO(berg): can we axe Context? have workflow put details in the body/headers/params instead? Context json.RawMessage Params struct { Header http.Header Query url.Values } // TODO(berg): explore changing this field to Path, as URL is misleading. It's never // an fqdn, only the path of the url. URL string Method string AccessToken string }
RequestOf provides a generic body we can target our unmarshaling into. We don't have to have this as some users may be happy with the OG Request. However, we can express the former with the latter here.