Revisited auth and user management endpoints

[psrok1]

Your checklist for this pull request

• I've read the contributing guideline.
• I've tested my changes by building and running the project, and testing changed functionality (if applicable)
• I've added automated tests for my change (if applicable, optional)
• I've updated documentation to reflect my change (if applicable)

REST API refactor checklist:

• Schemas:
  • All related schemas should be moved from schema.py to proper schema/<endpoint group>.py directory
  • Schemas should have separate Request and Response classes.
  • Inheritance is evil here, don't use it too much.
  • Remember that missing key, null and empty string could have different meaning:
    • missing key is viable for update requests when we don't want to set some attributes or want to use a default
    • null is viable for nullable arguments, non-persisted in database. Can be used in the same meaning as missing key.
    • empty string can be used for persisted fields
• Don't use obj.data.get(...) for required fields, use obj.data[...] and missing= defaults in Schema
• Don't call db.session.add(...) for persistent object (objects that are not new, but fetched from database)
• Whole data validation should be done by Schema's
• Complex, reusable parts of logic should be moved to model class methods or separate util functions
• All write actions must be properly logged

What is the new behaviour?

• Breaking change: /auth/profile is used instead of /user/<current login> for gathering current profile information.
  • /user/* and /group/* endpoints should be used only for user/group management.
  • /user/<login> needs manage_users capability even if login matches the name of currently authenticated user
• api_key issuer login is available for all users
• /api_key/* checks if provided id is correct UUID identifier
• correct /auth/register request body schema:
  
• /user/{login}/change_password moved from auth.py to user.py (/user prefixed, user management endpoint)
• correct /group/<name> response schema (it returns information about single group, not all groups):
  
• added missing POST/PUT /group/<name> missing request body schema
• correct response schema for PUT/DELETE /group/<name> and POST/PUT /group/<name>/member/<login>
• correct request schema for POST/PUT /user/<login>

Test plan

• Check if all auth/user/group management features available in frontend work correctly
• Most things should be covered by automated tests

[BonusPlay]

Initial pass, not tested, just styling/typing/convention review.

You said that

Inheritance is evil here, don't use it too much.

which is true, inheritance makes schemas much harder to read, but (sadly) I believe that it's the only way to have all schemas properly validated without deduplicating code.

Additionally I'd propose to add constraints on outgoing schemas. Example: UserItemResponseSchema. There's no reason not to add more constraints in there, as they might catch uninitialized variables later down the development.

[psrok1]

Agree that response schemas should also have non-nullable constraints.

I found that some fields missed NOT NULL on database model level, added appropriate migration.

[psrok1]

Migration tested using production database backup data: works well ✔️

[BonusPlay]

Not tested, just styling/typing/convention review.

PR too big for me to approve PR (as I'm not familiar enough with project).

[BonusPlay]

github hard, I need to approve PR otherwise it won't merge ._.

[msm-code]

unrelated, but can we start addding type annotations to malwarecage? :duck001:

[psrok1]

Along with Pydantic instead of Marshmallow? :duck001: