[
https://issues.apache.org/jira/browse/DIRSERVER-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15163267#comment-15163267
]
Emmanuel Lecharny commented on DIRSERVER-2125:
----------------------------------------------
Yes, that's it, we bypass all the checks :
{noformat}
processModifyAddPwdAttributes( entry, mods, pwdModDetails );
String csnVal = directoryService.getCSN().toString();
Modification csnMod = new DefaultModification( REPLACE_ATTRIBUTE,
directoryService.getAtProvider()
.getEntryCSN(), csnVal );
mods.add( csnMod );
ModifyOperationContext internalModifyCtx = new
ModifyOperationContext( adminSession );
internalModifyCtx.setPushToEvtInterceptor( true );
internalModifyCtx.setDn( modifyContext.getDn() );
internalModifyCtx.setEntry( entry );
internalModifyCtx.setModItems( mods );
// Directly update the database...
directoryService.getPartitionNexus().modify( internalModifyCtx );
{noformat}
We can bypass the checks done by the {{SchemaInterceptor}}, but we must be sure
we don't add a Single Value attribute twice. In other words, the
{{AuthenticationInterceptor}} class should always control the attributeType
presence before adding it.
> More than one value has been provided for the single-valued attribute:
> pwdAccountLockedTime
> -------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-2125
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2125
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 2.0.0-M20
> Reporter: lucas theisen
>
> I have now encountered this issue a couple times. I am not quite sure how,
> but {{pwdAccountLockedTime}} is getting multiple values set to it. This
> seems not to be a problem immediately (the directory works with multiple
> values), but I take daily backups and when I try to restore, I get:
> {code}
> processing failure: CONSTRAINT_VIOLATION: failed for MessageType : ADD_REQUEST
> Message ID : 6259
> Add Request :
> Entry
> dn[n]: uid=some.guy,ou=people,dc=example,dc=com
> objectClass: organizationalPerson
> objectClass: person
> objectClass: inetOrgPerson
> objectClass: portalPerson
> objectClass: top
> pwdAccountLockedTime: 20160131192519.758Z
> pwdAccountLockedTime: 20160131193013.986Z
> pwdAccountLockedTime: 20160131193020.941Z
> pwdAccountLockedTime: 20160131193026.911Z
> pwdAccountLockedTime: 20160131193036.580Z
> mail: [email protected]
> pwdFailureTime: 20160131192059.579Z
> pwdFailureTime: 20160131192108.556Z
> pwdFailureTime: 20160131192129.709Z
> pwdFailureTime: 20160131192142.260Z
> pwdFailureTime: 20160131192448.419Z
> pwdFailureTime: 20160131192457.637Z
> pwdFailureTime: 20160131192504.937Z
> pwdFailureTime: 20160131192519.758Z
> pwdFailureTime: 20160131193013.986Z
> pwdFailureTime: 20160131193020.941Z
> pwdFailureTime: 20160131193026.911Z
> pwdFailureTime: 20160131193036.580Z
> timeZone: America/New_York
> active: true
> cn: Some Guy
> creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
> modifiersName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
> userPassword: ????
> pwdHistory: ????
> pwdHistory: ????
> pwdHistory: ????
> pwdHistory: ????
> pwdHistory: ????
> pwdHistory: ????
> pwdHistory: ????
> pwdHistory: ????
> pwdHistory: ????
> pwdHistory: ????
> uid: some.guy
> entryUUID: 33b6e17c-fe72-4d28-85ea-9f72e27143d3
> givenName: Some
> entryParentId: 96c37a0c-48b0-4960-b3e1-e01057bb742f
> createTimestamp: 20150422005642.549Z
> entryCSN: 20160131193036.581000Z#000000#001#000000
> sn: Guy
> modifyTimestamp: 20151020122447.179Z
> entryDN: uid=some.guy,ou=people,dc=example,dc=com
> : ERR_278 More than one value has been provided for the single-valued
> attribute: pwdAccountLockedTime
> {code}
> My understanding is that the {{pwdAccountLockedTime}} _SHOULD_ be single
> valued, and as such, the bug is in allowing it to get set multiple times.
> I do not currently have steps to reproduce, and for now my team works around
> it with our restore automation (read the incoming ldif and strip out all bu
> the latest copy of this attribute before adding it to the directory)...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
