Allow sharing of investigations #3865

tillprochaska · 2024-09-17T09:19:44Z

This enables sharing of investigations with individual users by providing their full email address. Main changes are in 7cced50.

If you want to manually test cases including OAuth user groups, you can set up Keycloak in your development environment like this: https://docs.aleph.occrp.org/developers/how-to/development/identity-provider/

stchris · 2024-09-17T09:21:23Z

aleph/tests/test_permissions_api.py

+from aleph.logic.roles import create_group
+
+
+class PermissionsApiTestCase(TestCase):


Thanks for this! 🙏

stchris · 2024-09-17T09:30:21Z

aleph/views/roles_api.py

-            "total": 0,
-        }
+    parser = QueryParser(request.args, request.authz, limit=10)
+    if parser.prefix is None or len(parser.prefix) < 3:


I guess we could raise minimum length to 5 or 6 here, but it's a minor thing.

stchris

LGTM, thanks for this! Left some minor remarks which are fine to be considered later (or not at all)

This reverts commit d827e03.

This reverts commit f9c0819.

@stchris

As suggested by @stchris

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.

tillprochaska requested review from stchris, Rosencrantz and catileptic September 17, 2024 09:19

stchris reviewed Sep 17, 2024

View reviewed changes

stchris approved these changes Sep 17, 2024

View reviewed changes

tillprochaska added 4 commits September 17, 2024 17:55

Revert "Disables the user lookup endpoint"

903603c

This reverts commit d827e03.

Revert "Remove user lookup from investigation sharing screen"

03120b3

This reverts commit f9c0819.

Require full email address to share investigation with individual users

4ad53e0

Increase minimum parameter length for suggest endpoint

427d2c7

As suggested by @stchris

tillprochaska force-pushed the fix/share-investigations branch from 7cced50 to 427d2c7 Compare September 17, 2024 15:56

tillprochaska merged commit 2c03781 into release/4.0.0 Sep 18, 2024
3 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Allow sharing of investigations #3865

Allow sharing of investigations #3865

Uh oh!

tillprochaska commented Sep 17, 2024 •

edited

Loading

Uh oh!

stchris Sep 17, 2024

Uh oh!

stchris Sep 17, 2024

Uh oh!

tillprochaska Sep 17, 2024

Uh oh!

stchris left a comment

Uh oh!

Uh oh!

Uh oh!

		from aleph.logic.roles import create_group


		class PermissionsApiTestCase(TestCase):

Allow sharing of investigations #3865

Allow sharing of investigations #3865

Uh oh!

Conversation

tillprochaska commented Sep 17, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stchris Sep 17, 2024

Choose a reason for hiding this comment

Uh oh!

stchris Sep 17, 2024

Choose a reason for hiding this comment

Uh oh!

tillprochaska Sep 17, 2024

Choose a reason for hiding this comment

Uh oh!

stchris left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

tillprochaska commented Sep 17, 2024 •

edited

Loading