We are trying to modify Hydra to support an offline resiliency:
we want some of our setups to be resilient to temporal (2-3 hours) network outage.
As database deployed in the cloud it will be unavailable during these outages.
By resilience I mean the possibility for user to be logged in and refresh an existing session.
The idea is to make a “caching proxy” for datasource which caches some data needed for OAuth flow and uses that cache while the main datasource (PostgreSQL DB) is unreachable.
Since the environment for that setup is not trustworthy we cannot store data in local database and thinking of using in-memory encrypted cache inside the Hydra instance.
We found an option for us to create a custom DBAL plugin where we are going to override the standard behavior:
- Cache some data that is needed for login (e.g. clients, maybe sessions) from database
- Check if database is available and use cache to handle requests otherwise
- (Optional) Push cached data (sessions, tokens) back to database when it becomes available
We started to implement this DBAL plugin (yes, we know that you are discouraging from doing this).
We cannot find any examples (GCP plugin seems to be outdated and not working anymore).
And some concerns appeared at the very beginning of this work.
Your implementations of Registry interface are based on RegistryBase which contains private fields and methods and seems to be not reusable.
We don’t want to change anything besides data storage communication.
But it looks like we cannot just write new fosite_store implementations and switch existing ones without copying all Registries/Managers code.
That will lead us to stay on current version and possibility to damage something.
So, working on this option for a while we are no longer consider it as a good solution.
Another option is to fork Hydra repository and try to do the same internally, but it can be another bad way.
Could you please comment on this? Are there any other reasonable options you can see?