452e46 changes the way we handle authentication in tests. Previously, we used API keys to authenticate users. Now, as we don’t generate API keys for users by default anymore, we use session tokens (the same mechanism the UI uses as well). In general, authentication using session tokens and API keys is quite similar: In both cases, the token is passed as a request header.

However, there’s one significant difference between session tokens and API keys: When using API keys, data about the user (including group memberships) is loaded from the database on every request. When using session tokens, this data is cached in Redis for the lifetime of the session. For end users, this means they have to sign out and in again after their group memberships have been updated.

When I originally implemented this change in our tests, it didn’t affect any of the tests as none of them did rely on updating group memberships. However, I’ve since implemented and merged additional tests in #3865, including one test that covers updating the user’s group memberships after the initial sign in. When I rebased this branch to include these new tests, this particular test failed.

The solution for this is the same as for end users: In the test case, we need to reauthenticate the test user after updating the group memberships.

452e46 changes the way we handle authentication in tests. Previously, we used API keys to authenticate users. Now, as we don’t generate API keys for users by default anymore, we use session tokens (the same mechanism the UI uses as well). In general, authentication using session tokens and API keys is quite similar: In both cases, the token is passed as a request header.

However, there’s one significant difference between session tokens and API keys: When using API keys, data about the user (including group memberships) is loaded from the database on every request. When using session tokens, this data is cached in Redis for the lifetime of the session. For end users, this means they have to sign out and in again after their group memberships have been updated.

When I originally implemented this change in our tests, it didn’t affect any of the tests as none of them did rely on updating group memberships. However, I’ve since implemented and merged additional tests in #3865, including one test that covers updating the user’s group memberships after the initial sign in. When I rebased this branch to include these new tests, this particular test failed.

The solution for this is the same as for end users: In the test case, we need to reauthenticate the test user after updating the group memberships.

* Allow users to reset their API key

Fix #1027

* Only return API key once after it has been generated

* Add new UI to reset and display API key

How API keys are reset and displayed has changed since the initial version of API keys: Users will be able to view an API key exactly once after it has been created/reset. This requires a slightly different user interface. We’re also planning a few more changes to API keys in the future, and these UI changes prepare for that.

* Refactor existing settings screen

The existing settings UI was a little cluttered and unstructured. We’re going to add new settings in this PR and in follow-up PRs, so I took the time to clean up the UI (both visually and implementation-wise).

* Ensure that toasts are always visible, even when scrolling

This is a hacky workaround, but a proper fix would require quite some refactoring. Considering that this hack is pretty isolated and not going to affect any other parts of the UI and that we will need to upgrade to Blueprint 5 at some point anyway, I’ve opted for the quick-and-dirty solution for now.

* Do not display password setting when password auth is disabled

* Use session tokens for authentication in API tests

In the future, roles won’t have an API key by default anymore. As an alternative, we generate session tokens explicitly.

* Do not generate API tokens for new roles

Most users do not need API access so there’s no reason to generate an API key for them by default.

* Handle users without an API key properly in the settings UI

Previously, an API was generate automatically for new users, i.e. every user had an API key. This has now changed, and the settings UI needs to properly handle situations where a user doesn’t yet have an API key.

As this increases the complexity of the UI state, I’ve refactored the component to make use of a local reducer.

* Update wording to clarify that API keys are secrets

* Rename "reset_api_key" to "generate_api_key"

This method is now also used to generate an initial key for users who do not yet have an API key.

* Send email notification when API key is (re-)generated

* Extract logic to regenerate API keys into separate module

While the logic initially was quite simply, there will be more business logic related to API keys, e.g. sending notifications ahead of and when an API key has expired.

* Let API keys expire after 90 days

* Extract `generate_api_key` method from role model

Initially, I added this to the role model as the model to be consistent with the model's `set_password` method. However, as the logic to generate an API token has become more complex, it is clear that it shouldn't live in the model.

* Send notification when API keys are about to expire/have expired

* Display API key expiration date in UI

* Add CLI command to reset API key expiration of non-expiring API keys

* Replace use of deprecated `utcnow` method

https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow

* Remove unnecessary keys from API JSON response

Aleph represents both users and groups using the role model. However, some API keys (such as `has_password` or `has_api_key` are not relevant for groups).

* Add note to remind us to remove/update logic handling legacy API keys

* Send API key expiration notifications on a daily basis

* Fix Alembic migration order

We merged a different migration in the meantime (8adf50) and as a result Alembic wasn’t able to figure out how to upgrade the database unambiguously.

* Reauthenticate user in test to update session cache

452e46 changes the way we handle authentication in tests. Previously, we used API keys to authenticate users. Now, as we don’t generate API keys for users by default anymore, we use session tokens (the same mechanism the UI uses as well). In general, authentication using session tokens and API keys is quite similar: In both cases, the token is passed as a request header.

However, there’s one significant difference between session tokens and API keys: When using API keys, data about the user (including group memberships) is loaded from the database on every request. When using session tokens, this data is cached in Redis for the lifetime of the session. For end users, this means they have to sign out and in again after their group memberships have been updated.

When I originally implemented this change in our tests, it didn’t affect any of the tests as none of them did rely on updating group memberships. However, I’ve since implemented and merged additional tests in #3865, including one test that covers updating the user’s group memberships after the initial sign in. When I rebased this branch to include these new tests, this particular test failed.

The solution for this is the same as for end users: In the test case, we need to reauthenticate the test user after updating the group memberships.

* Update wording of API key notification emails based on feedback

* Use strict equality check

* Clarify that API keys expire when generating a new key

* Display different UI messages in case the API key has expired

* Fix Alembic migration order

We merged other migrations in the meantime and as a result Alembic wasn’t able to figure out how to upgrade the database unambiguously.