The tenant ID should be hashed and used as the key for the JSON blob of
relevant creds for any given tenant. Azure CSP interface methods that
need to source creds should call the internal `_source_creds` method,
either with a `tenant_id` or no parameters. That method will source the
creds. If a tenant ID is provided, it will source them from the Key
Vault. If not provided, it will return the default creds for the app
registration in the home tenant.
To satisfy security requirements, we need to explicitly track:
- when a user attempts to log in, successful or not
- when a user logs out
- whether or not the user associated with a request is logged in
The first two are satisfied by extra log statements and the last is a
new boolean field on the JSON logs.
This enables JSON logging for Celery workers if the LOG_JSON conig value
is set. It uses the same JsonFormatter class used by the Flask
applications. That class has been updated in two ways:
- It takes a `source` kwarg to define the log source for the formatter.
- The `msg` attribute of the log record is formatted with any arguments
that may have been passed. This is necessary for Celery to render task
type, completion time, etc. into the log output.
Debug mode allows route integration tests to raise explicit exceptions on
errors, instead of returning error pages. Some portions of the test
suite need to be able to ignore exceptions (the response is not under
test) so they use a separate pytest fixture version of the app and
client that are configured with debug disabled, as it would be in
production.
Celery provides a more robust set of queueing options for both tasks and
worker processes. Updates include:
- infrastructure necessary to run Celery, including celery entrypoint
- backgrounded functions are now imported directly from atst.jobs
- update tests as-needed
- update kubernetes worker pod command
This gives us better test isolation. Previously, we were manually
setting `g.current_user` with a factory instance and not cleaning it up
properly, which could break later tests.
`user_can` function built for Jinja template contexts should check
application, portfolio, and atat level permissions depending on what
resources are available on `g`.
A `before_request` hook queries the database for portfolios, requests,
and task orders based on the route arguments. The resources are added as
attributes on `g`. The portfolio context processor and the access
decorator now rely on those resources being available on `g`.
WIP: find major resources in before_request hook, apply to g
WIP: use g.portfolio for portfolio context processor
WIP: the access decorator should rely on the resources being available on g