You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
This is related to the PR #1583
For projects ACL's and api key we use a user cache in Redis. This cache is overridden at each login.
The project ACL is used for example by DocumentRessource to check if users have access to a project by getProjects/getProjectNames in User.java. It is finally using the field groups_by_applications returned by the Identity Provider.
Describe the solution you'd like
the cache should be made by another implementation class so the line writableUsers().saveOrUpdate(datashareUser); could be in a subclass of the OAuth2CookieFilter.processOAuthApiResponse
the user field containing the project could have another location in the json. It is now in groups_by_applications.datashare but it could be located elsewhere in the json returned by the Identity Provider. That could allow other deployments to use the IP configuration for project ACL without using another persistence location.
Additional context
see
When cache has been introduced #504.
latest refactor #1395
The text was updated successfully, but these errors were encountered:
bamthomas
changed the title
OAuth: remove hard coded groups_by_applications and users cache from OAuthCookieFilter
OAuth: remove hard coded groups_by_applications and users cache from OAuthCookieFilterOct 2, 2024
Is your feature request related to a problem? Please describe.
This is related to the PR #1583
For projects ACL's and api key we use a user cache in Redis. This cache is overridden at each login.
The project ACL is used for example by
DocumentRessource
to check if users have access to a project bygetProjects/getProjectNames
in User.java. It is finally using the fieldgroups_by_applications
returned by the Identity Provider.Describe the solution you'd like
writableUsers().saveOrUpdate(datashareUser);
could be in a subclass of theOAuth2CookieFilter.processOAuthApiResponse
groups_by_applications.datashare
but it could be located elsewhere in the json returned by the Identity Provider. That could allow other deployments to use the IP configuration for project ACL without using another persistence location.Additional context
see
When cache has been introduced #504.
latest refactor #1395
The text was updated successfully, but these errors were encountered: