# CsrfPlus
A plug-based CSRF (Cross-Site Request Forgery) protection library with accesses storing support.

Sometimes, you need more than a per-request CSRF tokens. This is why this Plug was created.
This plug supports storing tokens in any kind of storage system. And all you have to do is to
implement its `CsrfPlus.Store.Behaviour`. By doing so you will provide ways to put, get,
delete and other operations of accesses on that 'Store'.

## How it works?
When a request is made, this plug will check the request method type. Request methods intended
for reading data (GET, HEAD, OPTIONS) will be ignored, by default. The other requests will be
checked against the CSRF token stored in the connection session, in the `x-csrf-token` header
and the one stored in the configured Store. All those tokens must match to each other to be
considered valid. The first checkings are to ensure the tokens are given. Then, the token in
the session and the one in the Store are verified against each other. Later, the token on the
`x-csrf-token` header that is a signed version of the generated token with the configured secret
key will be verified against that secret key. If this verification succeeds, the returned verified
token will be checked against the token in the store. If this verification also succeeds, the
connection continues normally. Otherwise, if any of the checks fails, an exception will be raised
and used to build the error message and response status code.

## Usage
You can use CsrfPlus as a plug in your endpoint, router or in some plug pipeline. As this plug
uses connection session, it must be plugged after `Plug.Session` and `Plug.Conn.fetch_session/2`.
Also, this plug won't check requests origin. So, to have safer connections, use some CORS lib of
your choice before CsrfPlus. A good choice is the [Corsica]( project.

One of the princeples of this plug is to avoid the most to do "dark magic". As so, you must generate the token and its signed version,
provide an `:access_id` and normal token in the user session and, store both the token and the `access_id` in the
configured store and, finally, include the signed token in the `x-csrf-token` header. Usually, you do this step in
response to a GET method request, thinking of a JSON API. But you can also use this plug with heex template
pages/components. More on the examples section.

Anyway, we provide a helper function to get the tokens ready to be send in the response connection and stored
in the configured store. This function is `CsrfPlus.put_token/2`. You will still need to generate, at least,
the token and its signed version. And to generate the token and its signed version you can use `CsrfPlus.Token.generate/0` that will
give you back a new token tuple at every call, or you can use the `CsrfPlus.get_token_tuple/1` that uses the `conn` struct to try to reuse
the token in the connection session or generate a new one when it's not possible. The use of the later function is prefferable when using
_heex pages/components_.

When using CORS, remmember to add the `x-csrf-token` header to the allowed and exposed headers. Also enable/allow the
session credentials.

### The access
Tokens are stored as accesses and each access must have a unique id, the `access_id`. You can use `UUID.uuid4/0`
to generate a unique id.
This `access_id` must be the same as the token in the session and the one in the store. This is because CsrfPlus
will, when checking a request, retrieve the `access_id` from the session and then use it to load the token in the
store. A found token with the given access id will be used later to test the tokens from session and `x-csrf-token`
in the header.

### Examples

An example project that uses phoenix heex pages can be found [here](

At the moment, LiveViews are not supported as they have a kind of hard coded validation through `Plug.CSRFProtection`. So if you want to
use LiveViews you must follow the instructions at `Phoenix.LiveView` [docs](

For an usage example on JSON Apis, check [recaptcha]( **(backend)** and
[recaptcha-front]( **(frontend)**.

## How to install?
Simply, add `:csrf_plus` to you mix dependencies:

# mix.exs
def deps do
    {:plug, "~> 1.0"},
    {:csrf_plus, "~> 0.1"}

And then run `$ mix deps.get`.

## Setting it up

### Configs
`CsrfPlus` uses some configurations to get ready to run.

#### Token module
This module is responsible to generate and verify tokens.
You can create your own Token module, since you implement the `CsrfPlus.Token` behaviour.

This lib ships with a 'DefaultToken' module, that is used for that. But if you
want to set a custom Token module, use the config:

# config/config.exs
config :csrf_plus, CsrfPlus.Token, token_mod: YourTokenModule

When using the 'DefaultToken', you can define the function to be used to generate tokens
or use the default one.
To config the token generator function add the following to your config:

# config/config.exs
config :csrf_plus, CsrfPlus.Token, token_generation_fn: &your_function/0

Such a function must return a string (binary) that is the token itself. That
token must be unique.

Finally, if you want to use the 'DefaultToken' module, you should set the
`:secret_key` to be used to generate and verify tokens. That key must be at least 64
bytes long.

Config with:

# config/config.exs
config :csrf_plus, CsrfPlus.Token, secret_key: "a_good_strong_random_secret"

> #### Please note {: .info}
> This `:secret_key` is only needed if you are using the 'DefaultToken'
> module.

#### Store module
In short, the store module is the module that implements the Store behaviour
and will keep your generated tokens ready to be checked against. If any served
token is not on the store, it is considered as invalid. For more information about
Stores look at the `CsrfPlu.Store.Behaviour` module.
To config the used store module, add the following:

# config/config.exs
config :csrf_plus, CsrfPlus, store: YourStoreModule

There is no store set by default. But if you don't care about that, you can use
the builtin `CsrfPlus.Store.MemoryDb` store. As it names suggests, it will store
tokens (accesses, actually) in memory, using a `GenServer`.

If so, do:

# config/config.exs
config :csrf_plus, CsrfPlus, store: CsrfPlus.Store.MemoryDb 

### Options
The `CsrfPlus` plug accepts some options at its initialization.
The following options are available:

  * `:csrf_key` - The key under the token is stored in the connection session. Defaults to: `"_csrf_key_"`

  * `:allowed_methods` - The requests methods that are ignored by the CSRF token validations.
By defaut: `["GET", "HEAD", "OPTIONS"]`.

  * `:raise_exception?` - If true, exceptions thrown by `CsrfPlus` will not be caught, but reraised. Set this to false
  to use the `ErrorMapper` and have response error and status code set. Defaults to `false`.

  * `:error_mapper` - The module to be used to map exceptions to response status codes and error messages. The connection is halted
  after the error is set.

    There is a default module for that: `CsrfPlus.ErrorMapper`. But you can set your own module
    since it implements the `CsrfPlus.ErrorMapper` behaviour. The `ErrorMapper` `map` function will only be used when
    the option `:raise_exception?` is set to false.

### Supervisor
As the CSRF validation of this lib uses a store of tokens, it's a good practice to
let them have a life span. And to keep the Store of tokens updated by this rule, we
use a store manager `CsrfPlus.Store.Manager` that will check all the tokens in the store
and flag the expired tokens as so. That Manager can be started directly, but to make it
easier to use with the default `CsrfPlus.Store.MemoryDb` store, we provide a `CsrfPlus.Supervisor` that
will not only start them, but also keep them up.

To start the Supervisor include the following entry in your application start function:

# application.ex
def start(_type, _args) do

  children = [
    {CsrfPlus.Supervisor, opts}


Replace opts by the options you want to set for the `CsrfPlus.Store.Manager`.
For more information about the options look at the module documentation.