CORS middleware config options.
Middleware to avoid Cross-site request forgery attacks.
Middleware to avoid Cross-site request forgery attacks. More info on CSRF at: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
This middleware is modeled after the double submit cookie pattern: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie
When a user authenticates, embedNew
is used to send a random CSRF value as a cookie. (Alternatively,
an authenticating service can be wrapped in withNewToken
).
By default, for requests that are unsafe (PUT, POST, DELETE, PATCH), services protected by the validated
method in the
middleware will check that the csrf token is present in both the header headerName
and the cookie cookieName
.
Due to the Same-Origin policy, an attacker will be unable to reproduce this value in a
custom header, resulting in a 401 Unauthorized
response.
By default, requests with safe methods (such as GET, OPTIONS, HEAD) will have a new token embedded in them if there isn't one,
or will receive a refreshed token based off of the previous token to mitigate the BREACH vulnerability. If a request
contains an invalid token, regardless of whether it is a safe method, this middleware will fail it with
401 Unauthorized
. In this situation, your user(s) should clear their cookies for your page, to receive a new
token.
The default can be overridden by modifying the predicate
in validate
. It will, by default, check if the method is safe.
Thus, you can provide some whitelisting capability for certain kinds of requests.
We'd like to emphasize that you please follow proper design principles in creating endpoints, as to not mutate in what should otherwise be idempotent methods (i.e no dropping your DB in a GET method, or altering user data). Please do not use the CSRF protection from this middleware as a safety net for bad design.
Removes a trailing slash from Request path
Removes a trailing slash from Request path
If a route exists with a file style Uri, eg "/foo", this middleware will cause Requests with uri = "/foo" and uri = "/foo/" to match the route.
Handles HEAD requests as a GET without a body.
Handles HEAD requests as a GET without a body.
If the service returns the fallthrough response, the request is resubmitted as a GET. The resulting response's body is killed, but all headers are preserved. This is a naive, but correct, implementation of HEAD. Routes requiring more optimization should implement their own HEAD handler.
Middleware to add HTTP Strict Transport Security (HSTS) support adding the Strict Transport Security headers
Middleware to support wrapping json responses in jsonp.
Middleware to support wrapping json responses in jsonp.
Jsonp wrapping occurs when the request contains a parameter with the given name and
the request Content-Type is application/json
.
If the wrapping is done, the response Content-Type is changed into
application/javascript
and the appropriate jsonp callback is
applied.
Simple Middleware for Logging All Requests and Responses
Simple Middleware for Logging Requests As They Are Processed
Simple middleware for logging responses as they are processed
Middleware for lifting application/x-www-form-urlencoded bodies into the request query params.
Middleware for lifting application/x-www-form-urlencoded bodies into the request query params.
The params are merged into the existing paras _after_ the existing query params. This
means that if the query already contains the pair "foo" -> Some("bar"), parameters on
the body must be acessed through multiParams
.
Middleware for virtual host mapping
Middleware for virtual host mapping
The VirtualHost
middleware allows multiple services to be mapped
based on the org.http4s.headers.Host header of the org.http4s.Request.
CORS middleware config options. You can give an instance of this class to the CORS middleware, to specify its behavoir