Results 1 to 3 of 3

Thread: Problem with fields which contain multiple values

  1. #1

    Default Problem with fields which contain multiple values

    We've experienced some very weird troubles the last 5-6 months. In our project, we use spring-ldap 1.1-RC1. We had to use the release candidate, because that was the latest version around and it contained a bugfix which we needed.

    In our application, there are users with certain rights. Each user belongs to a department, which in turn belongs to an agency. It's possible that 1 user is administrator of different departments. In that case, his/her profile contains one or more fields with the name "administratorofdepartment". So let's say you have 3 departments, T001, T002 and T003. If user a is administrator of 2 departments, his profile contains "adminofdepartments: T002" and "adminofdepartments: T003".

    For some reason, every once and a while, those fields are erased from the LDAP. I've added logging in our webapplication, but I don't see any trace of those fields being erased. It's also quite hard to simulate this behavior, because every user who experienced this didn't do anything extraordinary. The only thing I can think of is that they executed an update of a user profile,one after the other. But since they've done this multiple times and on multiple different days, it's quite hard to believe that this is what causing the problem.

    This is the code to update a profile:
    Code:
    public void update(String username, Citizen citizen)
    {
    	DistinguishedName currentDn = buildDn(username);
    		
    	if(citizen.getLogin().getUsername().equals(username))
    	{
    		// SAME UID -> REBIND
    		DirContextAdapter contextAdapter = (DirContextAdapter) ldapTemplate.lookup(currentDn);
    
    		CitizenToAttributesMapper citizenToAttributesMapper = new CitizenToAttributesMapper(contextAdapter);
    		citizenToAttributesMapper.mapToAttributes(citizen);
    
    		ModificationItem[] modificationItems = contextAdapter.getModificationItems();
    			
    		ldapTemplate.modifyAttributes(currentDn, modificationItems);
    	}
    	else
    	{
    		// CHANGED UID -> BIND/UNBIND
    		DistinguishedName newDn = buildDn(citizen.getLogin().getUsername());
    
    		CitizenToAttributesMapper citizenToAttributesMapper = new CitizenToAttributesMapper();
    		citizenToAttributesMapper.mapToAttributes(citizen);
    
    		ldapTemplate.bind(newDn, citizenToAttributesMapper.getContextAdapter(), null);
    
    		ldapTemplate.unbind(currentDn);
    	}
    }
    It doesn't happen very often, but when it happens it's quite irritating. Especially for our customers, since we don't have a proper explanation for this.

    The only thing I can think of is to put extra logging in our DAO-component, to check which fields it wants to update. Then we can find out if he tries to remove those fields and which action triggers the removal.

    Now my question is, is this a known bug? Has someone ever experienced this before? It's really weird, because it happens only now and then and it's at random. Not that there's a huge load at that time. I've also checked whether this could be a threading problem or not, but then it 's weird that it only happens once a month.

    I've included the latest Spring-LDAP release in our project and I'm going to test every action again. Normally everything should work, but just in case ...

  2. #2
    Join Date
    Jul 2005
    Location
    Helsingborg, Sweden
    Posts
    504

    Default

    There were some issues with multi-valued attributes before 1.2, and that code went through quite significant changes. I can't say for sure that this is the cause of your problems, but nevertheless I highly recommend you to move away from 1.1, up to 1.2.1.

    In your second scenario, where the uid has changed, is there any specific reason why you don't do a rename instead of bind and unbind? An unbind is always a little scary, since not all attributes are always possible to recreate in the new entry; operational attributes (eg modifiersName) and userPassword for example. A rename will simply move the entry to the new dn. Any attribute changes may be performed after the move.

    I'll show you an example. Below is the code for the update method of the PersonDaoImpl class in our sample project spring-ldap-person:

    Code:
        public void update(Person person) {
            DistinguishedName originalDn = new DistinguishedName(person
                    .getPrimaryKey());
            DistinguishedName newDn = buildDn(person);
    
            if (!originalDn.equals(newDn)) {
                ldapOperations.rename(originalDn, newDn);
            }
    
            DirContextOperations ctx = (DirContextOperations) ldapOperations
                    .lookup(newDn);
            ldapOperations.modifyAttributes(newDn, setAttributes(ctx, person)
                    .getModificationItems());
    
            if (!originalDn.equals(newDn)) {
                person.setDn(ctx.getNameInNamespace());
                person.setPrimaryKey(ctx.getDn().toString());
            }
        }
    Ulrik Sandberg
    Jayway (www.jayway.com)
    Spring LDAP project member

  3. #3

    Default

    Thx for the information. I changed our project's dependencies, so now the latest version of Spring-ldap is used to perform all the LDAP operations. I hope our problem is fixed, but the problem is that we'll only know for sure within a few weeks (or even months).

    I didn't write that part of the code, so I'm only maintaining it. I have no idea why they do an unbind, but thanks for the advice (again).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •