Better configuration of auth-tokens

[smondet]

Diff: https://github.com/hammerlab/ketrew/compare/88a681f...7decfad

These commits make the authentication tokens more configurable:

• One can add “inline” tokens that do not require a filesystem (one step close to unikernels \o/)
• One can specify more than one path (because why not)

Of course, the “reloading” that the server can do only happens for files.

[rleonid]

Documentation:

• Are the authorization tokens mandatory, what happens if the list is empty.
• Which token of the list is used (first, last, sequentially until one works?)

Maybe put the two constructors authorized_tokens_path and authorized_token into a separate module (Athorized ...etc)?

At https://github.com/hammerlab/ketrew/compare/88a681f...7decfad#diff-63c5e94549fbfb495f15b0a7cda866eeR77 wouldn't you want to comment out the authorized_token ~name:"The-inline-one" "inlinetoken"; ?

[smondet]

Documentation:

• Are the authorization tokens mandatory, what happens if the list is empty.

Well, nobody can use the HTTP API, which is a bit akward but it's not wrong

• Which token of the list is used (first, last, sequentially until one works?)

Yes the first that works.

Where do you think this should go? (doc of configuration.mli? doc of config-file.md? or doc of the HTTP-API?

Maybe put the two constructors authorized_tokens_path and authorized_token into a separate module (Athorized ...etc)?

I think it's fine like this for now. The constructors of Configuration.t should be kind-of an EDSL too.

At https://github.com/hammerlab/ketrew/compare/88a681f...7decfad#diff-63c5e94549fbfb495f15b0a7cda866eeR77 wouldn't you want to comment out the authorized_token ~name:"The-inline-one" "inlinetoken"; ?

No it's fine, it tests both methods this way.

[rleonid]

Where do you think this should go? (doc of configuration.mli? doc of config-file.md? or doc of the HTTP-API?

Both?

Sounds good on the rest of the questions.

[smondet]

Everything adddressed or in some other issue.