OK understood. Thanks. -Hiranya
On Thu, Aug 30, 2012 at 11:28 AM, Sumedha Rubasinghe <[email protected]>wrote: > Hiranya, > Sanjeewa's concern is coming from an intermediate piece of code that went > into custom branch location. > I just went through the code with Lalaji. It seems the new logic added is > not relevant to this context. Let me explain in detail. > > As part of a fulfilling a customer requirement, we are adding basic token > refresh functionality. So the logic that should be implemented is as > follows: > > 1. Subscriber requests for a token to be refreshed. > 2. Check if a token exists for the given criteria > 3. If #2 is true, regenerate a new token > 4. Check if token mentioned in #2 is in the gateway cache. If yes, remove > it from cache > 5. Persist the new token > > This is a basic implementation of token refresh functionality where > following factors have not been addressed: > 1. A refreshed token will have it's validity period extended by the > globally configured time period > 2. Any subscriber having a valid login can get his application's token > refreshed (we do not have monetization capabilities as of now) > > Lalaji will refactor the implementation to remove newly added lines from > 'getKeyValidationInfo' method. > > > On Thu, Aug 30, 2012 at 10:56 AM, Hiranya Jayathilaka < > [email protected]> wrote: > >> Where does this piece of code come from? I looked at the APIKeyValidator >> class in 1.0.0 branch and this is the full implementation of the method: >> >> public APIKeyValidationInfoDTO getKeyValidationInfo(String context, String >> apiKey, >> String apiVersion) >> throws APISecurityException { >> String cacheKey = apiKey + ":" + context + ":" + apiVersion; >> APIKeyValidationInfoDTO info = (APIKeyValidationInfoDTO) >> infoCache.get(cacheKey); >> if (info != null) { >> return info; >> } >> >> synchronized (apiKey.intern()) { >> // We synchronize on the API key here to allow concurrent >> processing >> // of different API keys - However when a burst of requests with >> the >> // same key is encountered, only one will be allowed to execute >> the logic, >> // and the rest will pick the value from the cache. >> info = (APIKeyValidationInfoDTO) infoCache.get(cacheKey); >> if (info != null) { >> return info; >> } >> >> info = doGetKeyValidationInfo(context, apiVersion, apiKey); >> if (info != null) { >> infoCache.put(cacheKey, info); >> return info; >> } else { >> throw new >> APISecurityException(APISecurityConstants.API_AUTH_GENERAL_ERROR, >> "API key validator returned null"); >> } >> } >> } >> >> >> Looks very different from what you have posted. >> >> Thanks, >> Hiranya >> >> On Thu, Aug 30, 2012 at 5:17 AM, Sanjeewa Malalgoda <[email protected]>wrote: >> >>> Hi All, >>> Can someone please help me to understand following part of code in API >>> manager component. >>> Following method is available inside APIKeyValidator class. There i can >>> see we check in database >>> even we had cached key. AFAIU isAccessTokenExists() method should not >>> call if info object is >>> not null. Also we can see same code repeated inside synchronized block >>> and outside it. My suggestion >>> is we shouldn't look at db for each api call as far as we have cached >>> info(this adds additional overhead). >>> Also we have to remove repeated code from synchronized block. >>> >>> >>> public APIKeyValidationInfoDTO getKeyValidationInfo(String context, >>> String apiKey,String apiVersion) throws APISecurityException { >>> String cacheKey = apiKey + ":" + context + ":" + apiVersion; >>> APIKeyValidationInfoDTO info = (APIKeyValidationInfoDTO) >>> infoCache.get(cacheKey); >>> ApiMgtDAO dao=new ApiMgtDAO(); >>> try { >>> if (info != null) { >>> if (dao.isAccessTokenExists(apiKey)) { >>> This call doesn't make any sense because its just check is there a token >>> in IDN_OAUTH2_ACCESS_TOKEN table. >>> SQL > SELECT ACCESS_TOKEN FROM IDN_OAUTH2_ACCESS_TOKEN WHERE >>> ACCESS_TOKEN= apikey >>> if we have cached info object associated with that token then obviously >>> that token is in database as well. Please >>> correct me if i understood this in a wrong way. >>> >>> >>> >>> >>> Thanks. >>> -- >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +14084122715 | +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 >>> >>> >> >> >> -- >> Hiranya Jayathilaka >> Associate Technical Lead; >> WSO2 Inc.; http://wso2.org >> E-mail: [email protected]; Mobile: +94 77 633 3491 >> Blog: http://techfeast-hiranya.blogspot.com >> > > > > -- > /sumedha > m: +94 773017743 > b : bit.ly/sumedha > > -- Hiranya Jayathilaka Associate Technical Lead; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
