On Wed, Oct 28, 2015 at 10:20 AM, Darshana Gunawardana <[email protected]> wrote:
> > > On Wed, Oct 28, 2015 at 10:18 AM, Darshana Gunawardana <[email protected]> > wrote: > >> >> >> On Tue, Oct 27, 2015 at 10:24 AM, Johann Nallathamby <[email protected]> >> wrote: >> >>> Yes. This is a problem. I also see few other related problems and looks >>> like the code could be buggy as well. >>> >>> Looking at the code I see the following caches in oauth component. >>> 1. OAuthCache >>> 2. AppInfoCache >>> >> >> >> >>> 3. AuthorizationGrantCache >>> >> >> Checked with Pushpalanka on this. It seems we don't have other >> persistence layer for AuthorizationGrantCache, hence we need to store this >> on SessionDataStore. >> > And AuthorizationGrantCache use auth code or access token as its key, > hence no issue regarding key size for AuthorizationGrantCache. > Hope you have considered the case of encrypting the access token (and the auth code as well?). In which case the token string becomes much longer than its equivalent plain text. > > Thanks, > Darshana > >> >> >>> 4. ClaimCache >>> 5. SessionDataCache >>> >>> No (5) looks like a duplicate of the SessionDataCache >>> in authentication-framework component. In that case we should not use this >>> and use the one in authentication-framework. >>> >>> (1) - (4) doesn't seem they need to go to SessionDataStore. >>> SessionDataStore is used to store some values for a period of time that >>> corresponds to a particular request / session. I don't think (1), (2) and >>> (4) are of that sort. (1), (2) and (4) already have persistent storages and >>> have no problem if the cache expires. I.e. (1) and (2) are persisted in >>> OAuth2 tables and (4) in user store. So we shouldn't need SessionDataStore >>> for those. Not sure about (3), have to look into that bit more closely. >>> >>> @Darshana/Maduranga, can you guys please look into this immediately. >>> This could unnecessarily drop performance of OAuth2. >>> >>> Thanks. >>> >>> On Mon, Oct 26, 2015 at 5:18 PM, Nuwan Dias <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> The length of the column SESSION_ID of the IDN_AUTH_SESSION_STORE table >>>> is 100. But I see that the values written to that column are quite lengthy >>>> and inserts could fail for cases like email usernames or long tenant >>>> domains or long usernames, etc. See a sample value below. >>>> >>>> Eqnhj4j1X8ZJCW0ww56N7Hdzdvoa:[email protected]@carbon.super:am_application_scope >>>> default >>>> >>>> The value inserted to this column seem to be a combination of several >>>> values and hence has the potential to grow. Specially for tokens with >>>> several scopes. >>>> >>>> Is it right to insert values to this column in this format? Should we >>>> not change it since it looks to me like it'll be a problem with regard to >>>> column lengths? >>>> Thanks, >>>> NuwanD. >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Technical Lead - WSO2, Inc. http://wso2.com >>>> email : [email protected] >>>> Phone : +94 777 775 729 >>>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> *Johann Dilantha Nallathamby* >>> Technical Lead & Product Lead of WSO2 Identity Server >>> Governance Technologies Team >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - *+94777776950* >>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>> >> >> >> >> -- >> Regards, >> >> >> *Darshana Gunawardana*Senior Software Engineer >> WSO2 Inc.; http://wso2.com >> >> *E-mail: [email protected] <[email protected]>* >> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware >> > > > > -- > Regards, > > > *Darshana Gunawardana*Senior Software Engineer > WSO2 Inc.; http://wso2.com > > *E-mail: [email protected] <[email protected]>* > *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware > -- Nuwan Dias Technical Lead - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
