Hi Francesco, about the reworked patch: a bit late and I'm unsure, but wouldn't it be more consistent to also setFailedLogins(0) on successful login even if log.lastlogindate=false?
Otherwise the semantics of getFailedLogins() differs depending on the setting of log.lastlogindate, which looks counterintuitive to me, and makes e.g. locking a user after 3 failed login attempts impossible. Cheers, Guido > Gesendet: Donnerstag, 19. Juni 2014 um 11:06 Uhr > Von: "Francesco Chicchiriccò (JIRA)" <j...@apache.org> > An: dev@syncope.apache.org > Betreff: [jira] [Resolved] (SYNCOPE-507) User login date conditional logging > > > [ > https://issues.apache.org/jira/browse/SYNCOPE-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Francesco Chicchiriccò resolved SYNCOPE-507. > -------------------------------------------- > > Resolution: Fixed > > The patch provided was reworked to keep in any case the storage of failed > logins in case of wrong authentication. > This is in order to preserve the general security and to prevent brute force > attacks. > > > User login date conditional logging > > ----------------------------------- > > > > Key: SYNCOPE-507 > > URL: https://issues.apache.org/jira/browse/SYNCOPE-507 > > Project: Syncope > > Issue Type: Improvement > > Components: core > > Affects Versions: 1.1.7 > > Reporter: Yann Diorcet > > Assignee: Francesco Chicchiriccò > > Priority: Minor > > Fix For: 1.1.8, 1.2.0 > > > > Attachments: 0001-Conditional-authentication-DB-logs.patch > > > > > > When used aside other processes with huge IO usage, the REST call to > > syncope/cxf/users/self can be take lot of time to reply (on our machine up > > to 60 seconds). This is due to the DB update on lastLoggindDate, mysql > > takes lot of time to commit the modifications. > > Maybe add an option for disabling this feature (or restrict the update > > following a minimum time gap) can be a good idea > > > > -- > This message was sent by Atlassian JIRA > (v6.2#6252) >
