Documentation/guides

[tisboyo]

Can you provide guides or docs on how to:

• Run both server and client from same instance
• Create/use/view/revoke service keys

[codemation]

Hi @tisboyo , nice suggestions:

Run both server and client from same instance

In order to accomplish this, the following tasks will need to be performed:

• [x] Add Default Admin Prefix - GUI / API will need a default & configurable prefix to avoid overriding root routes
• [x] Create / edit Server Usage Documentation with prefix - Edit default readme and mkdocs with new usage options

Create/use/view/revoke service keys

Documentation on creating using service tokens is trivial, but revoking an issued service token will require more thought.

• [x] Create Service Token Usage Documentation

I created Add Support for Token revoking where I will create a channel for EasyAuthServer & EasyAuthClient to communicate ( so public keys are easier to exchange, revoked tokens can be communicated).

[codemation]

@tisboyo Feature providing support of "Run both server and client from same instance" provided in version 0.134

See Documentation on usage here

[tisboyo]

That appears to work exactly as I hoped. Noticing something, I may not have noticed before, but the admin page is handling all 404 pages and not just ones in /admin.

Loving the library, I can see it becoming very popular.

[codemation]

Token Revocation / Service account API / GUI usage completed in latest PR

Have a look via latest version: https://pypi.org/project/easy-auth/0.136/

This was a pretty major update to the EasyAuthServer / EasyAuthClient - which added support for EasyAuthServer forking & a channel between EasyAuthServer & EasyAuthClient for token information exchange & reducing setup complexity.

Keep in mind that a new field is required for EasyAuthServer / EasyAuthClient creation, 'auth_secret', this field allows the public key to be pulled and creates the channel for the server to push token updates to connected EasyAuthClient's.

@tisboyo check it out when you can.

• server usage
• client usage

Be sure to use the following to grab all new dependencies:

pip install -U easy-auth[all]

# run again to update( because pip is special)
pip install -U easy-auth[all]

[tisboyo]

So does this remove the need for the key files? Does the auth_secret replace the need for them? Looking through the changes, it looks like when the quorum database is being created, it's not using the credentials/settings for the main database, and is creating it's own sqlite file. Is this intentional?

[tisboyo]

Also since db_proxy.py is being written to on every startup, it causes uvicorn to auto restart in an endless loop when reload=True.

[codemation]

So does this remove the need for the key files? Does the auth_secret replace the need for them?

The key files are still an integral part of the asymmetric token generation. The EasyAuthServer will look for the .key in the specified key_path at startup. This key allows the EasyAuthServer to create tokens used for client authentication. The auth_secret is effectivly entrypoint authentication, that allows an EasyAuthClient to pull the .pub key. The .pub key, is used by EasyAuthClient to verify that a token originated( was created) by the same EasyAuthServer. Also any modifications of the token, which change its signature, also invalidating the token.

Looking through the changes, it looks like when the quorum database is being created, it's not using the credentials/settings for the main database, and is creating it's own sqlite file. Is this intentional?

The quorum database serves currently as a locking mechanism between processes. When an EasyAuthServer is started with multiple workers, 1 of workers needs to decide who will start the db_proxy & manager_proxy child processes( as we do not want n * db_proxies or manager_proxy). This could be better served by a simple lock.txt file though to prevent confusion.

[codemation]

@tisboyo fix pushed in latest release as per comment in #10 .

https://pypi.org/project/easy-auth/0.138/