I get it. But maybe a pub/sub strategy is too much. You could define some specific (not so regular) user events in your app that triggers the authorization data update, like going from a big module to another.
Additionally, reacting to 401 Unauthorized responses could help to deal with this (401 > fetch authorization data).
Additionally, reacting to 401 Unauthorized responses could help to deal with this (401 > fetch authorization data).
For sure. But the back-end will still need a way to be aware of permission changes or else recheck the permission store every request. (If you are still expecting changes to be immediate.)
That’s assuming we are targeting scalable workloads. If the service doesn’t need to scale and it also responsible for making the permission changes, then you might just be able to keep permissions loaded in memory, and update them as changes happen.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I get it. But maybe a pub/sub strategy is too much. You could define some specific (not so regular) user events in your app that triggers the authorization data update, like going from a big module to another.
Additionally, reacting to 401 Unauthorized responses could help to deal with this (401 > fetch authorization data).
For sure. But the back-end will still need a way to be aware of permission changes or else recheck the permission store every request. (If you are still expecting changes to be immediate.)
That’s assuming we are targeting scalable workloads. If the service doesn’t need to scale and it also responsible for making the permission changes, then you might just be able to keep permissions loaded in memory, and update them as changes happen.