Send config file via Web API

[DK318]

Blocked by #37

Clarification and motivation

When the Web API was being developed we had only vault backend implementation and in order to access API, we had to send a VaultToken. Now we need to make this API backend-agnostic and send these tokens in another way. I suggest sending a JSON-serialized config file.

Acceptance criteria

We are sending a JSON-serialized config file instead of VaultToken in order to access the API.

[dcastro]

This issue seems to conflict with #84. And honestly, I'm not sure what the answer is. We have to figure out how users will use the frontend. Once we know those requirements, we'll be able to figure out where the Web API should get its configuration from.

[dcastro]

Update: Here's what we need to do:

• [ ] The Web API should not get its configuration from a config file (see app/server/Main.hs)
• [ ] Instead, users should tell the Web API which backend they want to connect to and which credentials to use
  • Right now, we require a header named vault of type VaultToken to be present, but a token is not enough
  • We need to know the backend type (for now, it's just a string hardecoded to "vault-kv"), vault's address, mount and token.
  • One way of doing this could be to require a json-encoded header like Coffer-Backend: { "type": "vault-kv", "address": ... }

[Kariel-Myrr]

As I can see we're just dropping VaultToken so instead we can replace it with Config header

[Kariel-Myrr]

As I understand only and only one source of backend is this Header. So: each API call will contain info about one backend that it wants to use So Config and config related things are redundant now?

113 Issue description confirms this

[Kariel-Myrr]

Also line 65 repeats in each runCmd function. So we can just replace Config with SomeBackend in runCmd And it will reduce copy paste all over lib.Backend.Command module + do it's job

[dcastro]

As I can see we're just dropping VaultToken so instead we can replace it with Config header

Yes, please see my comment above where I suggest a header named Coffer-Backend.

each API call will contain info about one backend that it wants to use

Yes

So Config and config related things are redundant now?

Well, they're not redundant for the CLI, only for the Web API. If you specifically meant that runServer should not use readConfig anymore, then yes, that's true.

Also line 65 repeats in each runCmd function. So we can just replace Config with SomeBackend in runCmd And it will reduce copy paste all over lib.Backend.Command module + do it's job

The reason it's not abstracted out is because some commands may need to access 2 different backends. For example, copyCmd and renameCmd may be used to copy/move entries from one backend to another.