Clearing cache for everyone without Management API
We're putting together a weather API which is generally open for all but authorised users with their open API key and username/pass (as headers) get a different response to /locations and are allowed to request data for those locations. Since the URL is the same a simple ResponseCache policy would populate the cache with the general or specific user and then the other user type would be able to get that response. Have tried adjusting the CacheKey to include the unique values the specific user sends and that does keep the values going to the correct users.
The problem comes when we get a new forecast. I can call the public endpoints with the header specified in SkipCacheLookup which avoids checking the cache but does repopulate it from our backend server. However I can't send a request that emulates the specific user's request with the SkipCacheLookup because that requires their credentials.
Idea #1
If the user is specifying credentials we used different cache location and clear that via the Management API when a new forecast is made. But that means we need an automated script with our management credentials (seems to require Basic Auth)
Idea #2
If the user is specifying credentials we use a different cache with a much shorter expiring time. But that means our partners have to make slow requests to our server more often
Idea #3
I set up a public endpoint, only reachable with a specific apikey (maybe controlled via an appropriate API Product) that can flush the "different cache" as above. This would mean the partners still make occasional slow requests, but only when new data is available. But it also means I need a way to invalidate a cache from an API Proxy and I believe it is only achievable through the Management API.
Idea #4
Could the Invalidate Cache policy take a wildcard to in validate all keys that include a specific user marker?
Answer by dane knezic
·
Jul 11 at 09:49 AM
I think #2 is the best approach.
Re #1/#3 to clear an entire cache, it's only possible via Management API as you have mentioned. An API Proxy should not be making calls to the Management APIs.
Re #4 this is possible - you can store your cache key with key fragments eg your first fragment to correspond to the user.. You can then invalidate just using the first key fragment, and with the PurgeChildEntries option as true it should invalidate any other cache entries under that key fragment. I imagine though your first key fragment would correspond with a particular forecast rather than the user though?
I experimented with the PurgeChildEntries but could not get it to purge entries from another user. The general cache is populated with one KeyFragment "uri" and the authed cache is populated with two, the Apikey and the uri. Then when our special user calls with bypass-cache it repopulates the general cache and tried to invalidate auth cache using PurgeChildEntries and just the url fragment. I figured that would do something like "org_app_cache_uri_*". Since I could not get that to work I went with option #2 and will work on securely calling the Management API to purge the authed cache at the right time.
