On Wed, Jun 21, 2017 at 11:03 AM, Isura Karunaratne <is...@wso2.com> wrote:
> > > On Tue, Jun 20, 2017 at 11:29 PM, Johann Nallathamby <joh...@wso2.com> > wrote: > >> If these two handlers are disabled by default there shouldn't be any >> problem. According to default identity-event.properties file they are >> disabled. How come they get triggered then? >> > > Yes. By default the account lock/disabled features are disabled. If it is > required to use account lock/disable features, there should be a way to > store user properties. > Looks like we haven't used the property to check whether the listener is enabled or disabled although we have defined in identity-event.properties. Therefore the handlers get fired on pre-authentications > > Also, if the um_user_attribute table is not there, most of the use cases > will be broken. (Add User/ Update User/ Get Users ...). So, I think that > user store is incomplete. > > Thanks > Isura. > > >> >> On Tue, Jun 20, 2017 at 7:25 PM, Farasath Ahamed <farasa...@wso2.com> >> wrote: >> >>> Hi, >>> >>> The minimum requirement to write a custom JDBC user store manager so far >>> (before IS 5.3.0) was to simply override the doAuthenticate() method. So a >>> custom user store that was written for 5.0.0 worked without any >>> modifications (may be dependency changes). >>> >>> But when we use the same code on IS 5.3.0, the custom user store >>> implementations that only override the doAuthenticate() are broken because >>> account disabled[1] and account locked[2] handlers introduced in IS 5.3.0. >>> >>> These two handlers call the getUserClaimValues() method of the >>> userstore to retrieve some claims. Since we haven't overridden the method >>> in custom userstore implementation it calls the super class. This leads to >>> trying to find the claims from a non-existing table[3]. >>> >>> One way to solve is to override the getUserClaimValues() method. But in >>> the PoV of the extension developer, this would be an unnecessary step if >>> the custom user store is just used for authentication only as explained in >>> [4]. >>> >>> Even in the official docs[5], we do not have any mention of having to >>> implement the getUserClaimValues() method. >>> >>> What would be the correct and the most efficient way to resolve this? >>> Appreciate your thoughts. >>> >>> >>> >>> [1] https://github.com/wso2-extensions/identity-event-handle >>> r-account-lock/blob/master/components/org.wso2.carbon.identi >>> ty.handler.event.account.lock/src/main/java/org/wso2/carbon/ >>> identity/handler/event/account/lock/AccountDisableHandler.java#L89 >>> >>> [2] https://github.com/wso2-extensions/identity-event-handle >>> r-account-lock/blob/master/components/org.wso2.carbon.identi >>> ty.handler.event.account.lock/src/main/java/org/wso2/carbon/ >>> identity/handler/event/account/lock/AccountLockHandler.java#L186 >>> >>> [3] https://wso2.org/jira/browse/IDENTITY-6074?focusedCommen >>> tId=134555&page=com.atlassian.jira.plugin.system.issuetabpan >>> els:comment-tabpanel#comment-134555 >>> >>> [4] https://wso2.org/jira/browse/IDENTITY-6074 >>> >>> >>> >>> >>> Thanks, >>> Farasath Ahamed >>> Software Engineer, WSO2 Inc.; http://wso2.com >>> Mobile: +94777603866 >>> Blog: blog.farazath.com >>> Twitter: @farazath619 <https://twitter.com/farazath619> >>> <http://wso2.com/signature> >>> >>> >>> >> >> >> -- >> Thanks & Regards, >> >> *Johann Dilantha Nallathamby* >> Senior Technical Lead - WSO2 Identity Server >> Governance Technologies Team >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >> >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > > *Isura Dilhara Karunaratne* > Senior Software Engineer | WSO2 > Email: is...@wso2.com > Mob : +94 772 254 810 <+94%2077%20225%204810> > Blog : http://isurad.blogspot.com/ > > > >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev