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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
