lonelyvikingmichael / litestar-users Goto Github PK

Support for MFA would be another essential feature. Integration could be done with passlib as well, using its TOTP capabilities.

• Use timed JWT tokens for user verification after registration
• Add necessary db columns
• Update schemas

Currently it's only possible to create roles manually or via seeding scripts. We should add role based methods to UserService at the very least and create new route handlers at most.

Edit: The same applies to adding/revoking roles to/from users

Typing is not terrible, but can definitely improve. MyPy will surely fail

Route handler typing was not updated after JWT support was added, this should be addressed.

Needs investigation.

With the merge of #23 , role based authorization is no longer a given. We should remove the roles relationship from the User mixin and make it a seperate opt-in.

Not only will this be cleaner, it will also allow for something like this wherever roles are integrated:

if not hasattr(request.user, 'roles'):
    raise ImproperlyConfiguredException("user roles are not set up")

Developers will need to subclass UserService in order to write their own pre/post operation hooks for login, register, update etc. This likely requires an update to config and typing.

Use mkdocs for documentation once the API is stable

So far we're pretty much only testing the API endpoints, and even then not for all common scenarios.
There should be unit tests for the repositories, services, guards etc.

Leverage Starlite's CLI tools to create users/roles

The user will be verified if "is_verified": true is part of the JSON payload

A mechanism should be put in place to address this, with care when a user might be created programmatically outside of the REST API scope by an administrator who wishes to bypass verification case by case.

Currently we're using factory patterns to inject configurations into route handlers and service layers.
This can be cleaned up somewhat by storing the StarliteUsersConfig object in app.state and using dependency injection to retrieve values.

Add two new handlers forgot_password and reset_password - the former emits a token, the later verifies and consumes a token.

As it is, the user service and repository only caters for SQLAlchemy models.
Other implementations to consider:

• Tortoise ORM
• Piccolo ORM

Add a configurable Role table, as well as a RoleUser association object. We'll use this to implement authorisation logic via Starlite Guards.

All primary keys are currently bound to SQLAlchemy/Postgresql UUID types, we should support generic DB back ends and perhaps allow for auto-incrementing integers.

We need a strategy to implement SQLA 2.0 mixins while maintaining backwards compatibility with 1.4

Look into allowing users to log in with a custom identifier, i.e. username instead of just via email.