Commit Graph

3 Commits

Author SHA1 Message Date
Marek Pikuła
7296c5d9e0 Make the AUTH_TYPE validator more general
- allow any casing style
- use Basic th by default if the string is left empty
- set some default values for user-password pair for BasicAuth

Signed-off-by: Marek Pikuła <marek.pikula@embevity.com>
2023-04-22 05:30:58 +00:00
iFargle
0aa0257b6e test 2023-04-22 13:02:53 +09:00
Marek Pikuła
fe7a3667d4 Complete the major refactor
Major part of #73

Unfortunately, it wasn't possible to split it to multiple smaller
commits, since the changes touched the entire application substantially.
Here is a short list of major changes:

1. Create a separate library (headscale-api), which is used as a
   convenient abstraction layer providing Pythonic interface with
   Pydantic. Headscale API is fully asynchronous library, benefitting
   from improved concurrency for backend requests thus increasing page
   load speed, e.g., on "Machines" page.
2. Create a common common, validated with flask-pydantic API passthrough
   layer from GUI to the backend.
3. Move authentication to a separate (auth.py), consolidating the
   functionality in a single place (with better place for expansion in
   the future).
4. Move configuration management to a separate module (config.py). Use
   Pydantic's BaseSettings for reading values from environment, with
   extensive validation and error reporting.
5. Reduce the number of health checks.
    - Now, most are performed during server initialization. If any test
      fails, the server is started in tainted mode, with only the error
      page exposed (thus reducing the surface of attack in invalid
      state).
    - Key checks are implicit in the requests to the backend and
      guarded by `@headscale.key_check_guard` decorator.
    - Key renewal is moved to server-side scheduler.
6. Introduce type hints to the level satisfactory for mypy static
   analysis. Also, enable some other linters in CI and add optional
   pre-commit hooks.
7. Properly handle some error states. Instead of returning success and
   handling different responses, if something fails, there is HTTP error
   code and standard response for it.
8. General formatting, small rewrites for clarity and more idiomatic
   Python constructs.

Signed-off-by: Marek Pikuła <marek.pikula@embevity.com>
2023-04-21 06:02:29 +00:00