CI Token management

[jbroillet]

It could be useful if the api-key could be set when doing a push of a new project.

Example with docatl: docatl push docs.zip newproject 1.0.0 --api-key 1a558b3687abc41fb9dd2f1ec9459271

Then, no token claim is possible for "newproject" project and the token is the token set.

[fliiiix]

Love that idea :+1: will you create a MR for this?

[reglim]

This won't work with the current implementation, because the token and hash is generated on the server side:

# def claim():
token = secrets.token_hex(16)
salt = os.urandom(32)
token_hash = calculate_token(token, salt)
table.insert({"name": project, "token": token_hash, "salt": salt.hex()})

What I'd do instead is add a flag claim or something similar. The API would then create the token, hash it and return it, which would be very similar to calling claim manually.

[johannesloibl]

I don't get why abf8499 was not merged. I'm just rying to do exactly the same thing. Using a Docat deployment that is automtatically fed from a CI job, while readers of the documentation shall have no permissions to delete/upload anything. Any progress on alternatives yet?

[fliiiix]

you can always mount in a custom nginx config which protects the /api routes with basic auth

but i will consider this use-case if we do a docat v2