Api authentication with tokens

[PizieDust]

closes #38

This PR introduces many changes, including a refactoring of how we check for csrf tokens.
In this PR:

• We can now have both session authentication and api token authentication (both stateful and stateless)
• Routes which change state are all converted to POST requests so that we can do the appropriate verifications.

The following endpoints can be accessed via the API

• /api/volume/delete
• /api/volume/create
• /api/volume/download
• /api/volume/upload
• /api/unikernel/destroy
• /api/unikernel/restart
• /api/unikernel/create

[hannesm]

One question I have is: which endpoints should be accessible with an API token? All of them? As many as possible? Or is there a plan / strategy which endpoints?

I.e. does a "change password" endpoint make sense to be available with a token? The underlying question is as well what permission does a token have / should a user when creating a token assign permissions to it? These are open design questions.

[PizieDust]

One question I have is: which endpoints should be accessible with an API token? All of them? As many as possible? Or is there a plan / strategy which endpoints?

I.e. does a "change password" endpoint make sense to be available with a token? The underlying question is as well what permission does a token have / should a user when creating a token assign permissions to it? These are open design questions.

I think the endpoints that should be accessible with the token should be endpoints that do anything with albatross (creating a unikernel, volumes, destroying them etc) and maybe requesting new tokens.

For other activities, I think these should only be done via the dashboard

[PizieDust]

One question I have is: which endpoints should be accessible with an API token? All of them? As many as possible? Or is there a plan / strategy which endpoints?

I.e. does a "change password" endpoint make sense to be available with a token? The underlying question is as well what permission does a token have / should a user when creating a token assign permissions to it? These are open design questions.

We can add permissions to the tokens, I think that's a great idea, I can have another PR with that

[hannesm]

I think the endpoints that should be accessible with the token should be endpoints that do anything with albatross (creating a unikernel, volumes, destroying them etc) and maybe requesting new tokens.

I completely agree, and would appreciate if we add - in this PR - a flag for authenticate ~token_is_ok:bool. Please let us not dive into the potential permission implementations.

I would not add requesting new tokens to the set of endpoints that can be done with a token.

To be more explicit, I'd guess the following endpoints are fine with a token:

• /api/volume/delete
• /api/volume/create
• /api/volume/download
• /api/volume/upload
• /api/unikernel/destroy
• /api/unikernel/restart
• /api/unikernel/create

Would you agree? Is there something missing?

[PizieDust]

I think the endpoints that should be accessible with the token should be endpoints that do anything with albatross (creating a unikernel, volumes, destroying them etc) and maybe requesting new tokens.

I completely agree, and would appreciate if we add - in this PR - a flag for authenticate ~token_is_ok:bool. Please let us not dive into the potential permission implementations.

I would not add requesting new tokens to the set of endpoints that can be done with a token.

To be more explicit, I'd guess the following endpoints are fine with a token:

• /api/volume/delete
• /api/volume/create
• /api/volume/download
• /api/volume/upload
• /api/unikernel/destroy
• /api/unikernel/restart
• /api/unikernel/create

Would you agree? Is there something missing?

This sounds great. I definitely agree