feat(backend): added FusionAuth settings to the config endpoint#345
feat(backend): added FusionAuth settings to the config endpoint#345allynt wants to merge 60 commits intodevelopmentfrom
Conversation
* feat(backend): refactor: adding pdm and updating docker Massive refactor of dashboard. Switching from pipenv to pdm. Changed usage of Docker and docker-compose. Updated all dependencies. Made a few minor code changes b/c of deprecated features of new dependencies. Updated documentation.
Added an instance of FusionAuth to use w/ docker-compose during development. Unfortunately, this isn't much use when actually running the dashboard because all the other safers comoponents (chatbot, gateway, etc.) require token authentication against the _real_ FusionAuth instance.
Updated testing configuration in order to support `pytest-html-reporter`.
Added a colored logger for development. Tweaked logging configuration just a bit to make it a bit prettier and a bit less verbose.
Refactored settings to bring it in line w/ other astrosat projects
* feat(backend): remove UserProfile model Removing UserProfile model. This PR deletes the admins, serializers, and views, signals, etc. associated w/ profiles. It also removes the 1to1 relationship between profiles and users in one migration, then completely removes the model in another migration. Finally, a third migration replaces the model w/ a JSONField. That field can be synchronised to/from the gateway. I still need to write the actual synchronisation function, but that must wait until after the authentication mechanism is refactored and there is a gateway client to use.
Added a ModelManager and QuerySet that allows models to be retrieved from remote APIs but still treats them internally as a django model w/ serializers, views, etc. Also added a class to act as a safers gateway client. Initially this will be used for the remote API when retrieving organizations. But in the long term I will replace all explicit calls to the requests library with this class.
I will eventually replace the organization and role models w/ TransientModels. This commit removes the current relationship fields to to the old organization and role models.
Added new Organization and Role models. These use CachedTransientModelManagers to retrieve their content from remote APIs.
Added organization_name and role_name to users. Moved organization and role to properties.
refactor organizations and roles
* feat(backend): removed references to allauth and knox Removed all references to django-allauth and django-knox (and their DRF equivalents). A future PR will add "proper" OAuth2 authentication for safers-dashboard-api. Local authentication via REST will no longer be supported as all safers users must be registered with FusionAuth. Also removed the existing Oauth code. This was a poor mixture of performing oauth authentication against FusionAuth and knox authentication against DRF. This will be replaced by "proper" oauth authentication where the dashboard validates tokens against FusionAuth.
Using drf-spectacular to generate swagger schemas. This is a more modern better-maintained library. The old drf-yasg helper code has been left in and will be removed eventually on a view-by-view basis. Also removed django-debug-toolbar which doesn't really make sense in a pure API. And stopped restricting admin access based on groups - it's non-standard and just confuses things.
feat(backend): swap drf-yasg for drf-spectacular
Added a django app for authentication.
Update UserSerializers. Since they are not directly being used for registration, they no longer need to be complex.
feat(backend): added auth app
Renamed config view to settings view. Because that's what it is - a view of the SafersSettings instance.
feat(backend): renamed config view to settings view
Several of the views still used the old names for various settings variables (GATEWAY_API_URL) for instance. This PR renamed them.
* feat(backend): refactor data views Simplified the data views; this is the first of several PRs. This one removes all of the conditional statements for returning WMS vs WMTS data; it will always return WMTS.
Added colors to SiteProfile to allow me to easily distinguish different sites.
feat(backend): added colors to SiteProfile
When starting from scratch, the backend was trying to access tables before they were created e.g. during the migration phase, but at that point, the cache tables didn't yet exist. I switched the cache tables creation to be the first thing in the script and it all now seems to work as expected.
Added thumbnails to camera media. Also started migrating from drf-yasg to drf-spectacular. Also removed lots of unneeded code.
feat(backend): added thumbnails to cameramedia
Added is_professional property to users. Also added a try/catch block in case the django cache is not yet setup when drf-spectacular generates schemas which use organizations & roles.
The role title uppercased the first letter of each word, but still had an underscore between words. I've added a replace call to replace any underscore with a space, so as to make it look better in frontend dropdowns.
The organization title uppercased the first letter of each word, but still had an underscore between words. I've added a replace call to replace any underscore with a space, so as to make it look better in frontend dropdowns.
Added a fixture containing the content for generating test messages. In particular this includes a test notification message. There are some changes to the notification model and serializer that were required for this - namely removing references to the outdated Organization model.
feat(backend): add a fixture for generating test messages
When updating a user profile, synchronise those changes w/ the gateway as well. Also defined a custom mixin to restrict updates to PUTs and not PATCHes.
feat(backend): propagate profile updates to gateway
Enable deleting user locally and from FusionAuth. Also improved the reshape_auth_errors function so theat missing "non_form_field" errors are not included.
Made propagating deletion of a dashboard user to the corresponding user in FusionAuth dependant on a setting. There may be users who wish to no longer use the dashboard, but still use the chatbot or other safers components.
feat(backend): enable deleting user
Renamed AOI files to better indicate that they are GeoJSON files meant for importing rather than JSON fixture files.
* feat(backend): configured profiling Configured profiling using silk. Also came up w/ a way to exclude specific views from profiling. Future PRs will add profiling to specific views as needed.
Fixed refresh view. Invalid access tokens are now deleted.
feat(backend): fix refresh view
Do not generate .prof files during profiling.
Added FusionAuth settings (like the time_to_live of the access_token and refresh_token) to the output of the "/api/config" endpoint. Also wrapped the existing AUTH_CLIENT in a class so I can add extra methods as needed.
| "auth_settings", | ||
| ) | ||
|
|
||
| auth_settings = serializers.SerializerMethodField() |
There was a problem hiding this comment.
What is the purpose of exposing this in the settings?
i.e. If a token's expiry is needed for when to refresh a token, I'd expect that to be produced alongside the token itsself, is this for some other purpose?
There was a problem hiding this comment.
🤔 Well, the access_token expiry is supplied with the token. It's the refresh_token expiry that we were missing.
At the moment, the refresh_token doesn't get replaced when we hit the RefreshView, only the access_token. So we wanted a way to tell the client when the initial refresh_token would expire.
To be honest, Mark and I were getting confused about how best to handle refresh (if safers are not willing to implement "refresh token rotation").
There was a problem hiding this comment.
Huh, yeah I guess if there is no way to refresh the refresh token, then the session just ends after the expiry, requiring actual re-login.
Perhaps RefreshView.post / TokenSerialiser could also return say refresh_expires_in?
There was a problem hiding this comment.
Yeah, but that expiry time would be constant based on when the session started. We want to know when it will end just in case the client wants to popup a message a few minutes before saying something like "you should save your work and re-authenticate".
There was a problem hiding this comment.
Ah right, what I mean is:
When fetching a refresh token, alongside the refresh token, have the backend also return e.g. refresh_expires_at with the timestamp of when the refresh token will expire. I'm worried about the frontend trying to "guess" what the exact time of the refresh expiry will be by calculating now() + refresh_token_time_to_live, whereas we could explicitly provide the exact expiry timestamp. Am I misunderstanding?
R2ZER0
left a comment
There was a problem hiding this comment.
- Keep expiry info alongside the token (i.e. same request/response)
- Use absolute timestamps rather than time deltas
Added FusionAuth settings (like the time_to_live of the access_token and refresh_token) to the output of the "/api/config" endpoint.
Also wrapped the existing AUTH_CLIENT in a class so I can add extra methods as needed.