feat: UI changes for Authz caching

[krithika369]

This MR mainly adds a small UI change to warn the users that, when updating permissions for a project, changes may take up to X minutes to take effect in the individual components. Since the individual components may set any value for KeyExpirySeconds, a new MaxKeyExpirySeconds has been introduced in api/pkg/authz/enforcer/enforcer.go which is hard-coded to 10 minutes. This means that, components will not be allowed to set key expiry > this value (this will be the X).

Illustration

Changes

• api/cmd/main.go - Supply UI env var REACT_APP_MAX_AUTHZ_CACHE_EXPIRY_MINUTES. When doing this, whether Authz and caching are enabled on the MLP app does not matter because they could be turned off on MLP but turned on in Turing, Merlin, etc.
• api/pkg/authz/enforcer/enforcer.go - Add MaxKeyExpirySeconds and a check to ensure that, when initialising the enforcer, the configured KeyExpirySeconds cannot be larger.
• ui/packages/app/src/config.js - Add MAX_AUTHZ_CACHE_EXPIRY_MINUTES config
• ui/packages/app/src/project_setting/user_role/SubmitUserRoleForm.js - Add info in the edit user permissions form

[deadlycoconuts]

The changes LGTM but just to understand the intention of the changes further, REACT_APP_MAX_AUTHZ_CACHE_EXPIRY_MINUTES is expected to be 'fixed' as the default value 600 / 60 minutes right? i.e. we aren't expecting anyone to be manually toggling that UI env var, are we?

[krithika369]

The changes LGTM but just to understand the intention of the changes further, REACT_APP_MAX_AUTHZ_CACHE_EXPIRY_MINUTES is expected to be 'fixed' as the default value 600 / 60 minutes right? i.e. we aren't expecting anyone to be manually toggling that UI env var, are we?

Correct. However the env var is still useful when the UI is not being served by the API (as with local dev).

[krithika369]

Thank for the quick review, @deadlycoconuts ! Will be merging this shortly.