Yes i think this should work and it will make our life easy :) Lets isolate user flows associated with cache. Please add if i missed anything.
01. Invoke API and then we need to add validation information to cache. 02. Delete Application - delete all tokens associated with application 03. Remove subscription - remove cache entries associated with unsubscribed API. 04. Remove API - remove cache entries associated with API. 05. Regenerate access token - remove cache entry for previous token. 06. Revoke access token - then remove all cache entries assicated with revoked token. 07. Revoke access tokens by application , user - remove cache entries. Also as discussed need to check the effect of having 2 cache with 2 different validity periods. And what happen if one cache expired while other is still pointing to it. Lets carefully evaluate these flows and fix this. Thanks, sanjeewa. On Wed, May 6, 2015 at 11:44 AM, Uvindra Dias Jayasinha <[email protected]> wrote: > +1, Looks good to me. > > On 6 May 2015 at 11:34, Amila De Silva <[email protected]> wrote: > >> Hi All, >> >> When caching is enabled on Gateway, KeyValidationInfoDTO object is kept >> in the cache against a cache key having the following structure; >> >> cacheKey = accessToken + ":" + apiContext + "/" + apiVersion + >> resourceUri + ":" + httpVerb + ":" + authLevel; >> >> This structure makes cache retrievals efficient, but poses several >> problems when removing entries. >> >> For example, when removing an API subscribed under an Application, we >> have to delete cache entries associated with that API. But since the cache >> key is a composition of several parts, finding cache entries related to a >> given API is not a straightforward task. >> >> With the existing implementation, following steps are performed when >> removing entries linked with a particular API, >> a. Finding all Applications the API is subscribed to >> b. Getting all active tokens issued for those Applications. >> c. Creating all possible cache keys that could be present in the key >> cache. >> d. Calling cache.remove on all the keys created >> >> Since we have access to the database in which tokens are stored, we have >> the ability of finding all the tokens associated with an API. But when >> having a third party Key Manager, this option won't work. Therefore a >> different mechanism is needed to find Cache entries associated with an API. >> >> Proposed solution is to introduce a second cache, which acts as an index >> for the main (existing) cache. Structure of the existing cache and the >> cache Key will remain the same. >> >> *Structure of the new cache * >> >> The combination of apicontext, version will be used as the cache key and >> the entry will be an APIEntry. Structure of the APIEntry will be like this. >> >> [image: Inline image 4] >> >> When needed to delete cache entries for an API, first the Index cache >> will be looked up using API context + version as the key. This will return >> all the ApplicationEntries which are present in the main cache and also to >> which the API has subscribed to. ApplicationEntry will have a list of cache >> keys, which are present in the main cache, and which contains a token >> obtained under the enclosing Application. >> >> We have to add entries to the Indexing cache at the same time we add a >> new entry to main cache. >> >> Will explain how different invalidation tasks are performed by only using >> these two caches in a mail to follow. >> >> Would highly appreciate your thoughts on this approach. >> > > > > -- > Regards, > Uvindra > > Mobile: 777733962 > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
