directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Flavio Minori" <flavio.min...@topcs.it>
Subject R: R: [Attributes manipulation] How to manipulate attributes inside the server
Date Wed, 21 Mar 2007 08:36:29 GMT
Hmmmm .. I am not so sure .. 
Why can I connect to ApacheDS with this 2 different DN ?

DN1: uid=steveharris, ou=people, dc=irons

DN2: uid=STEVEHARRIS, ou=people, dc=irons

Only DN1 exists!

Right now I am using APACHE DS 1.0.1

Flavio

________________________________________
Da: akarasulu@gmail.com [mailto:akarasulu@gmail.com] Per conto di Alex
Karasulu
Inviato: martedì 20 marzo 2007 18.41
A: Apache Directory Developers List; elecharny@iktek.com
Oggetto: Re: R: [Attributes manipulation] How to manipulate attributes
inside the server

Hi,

I think it's significant to mention that the uid attribute type is
caseExactMatch.  So uid=STEVEHARRIS 
is not the same as uid=steveharris.  

On 3/20/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
I would say, 99% Apacheds bug we are trying to fix reight now ;)

I don't agree that this is an ApacheDS bug for the reasons stated above.  If

the attribute was caseIgnoreMatch like CN then I could suspect an issue w/ 
ApacheDS.

Alex
On 3/20/07, Flavio Minori < flavio.minori@topcs.it> wrote:
Hi Emmanuel,
excuse me if the mail is probably out of topic but I want to report this: 

In my Ldap server I have this account:

DN: uid=STEVEHARRIS, ou=people, dc=irons

and in the OrganizationalRole I have the roleOccupant attribute setted to:

roleOccupant: uid=STEVEHARRIS, ou=people, dc=irons 

Why Acegi doesn't retrieve authorities correctly?

If I change the roleOccupant attribute:

roleOccupant: uid=steveharris, ou=people, dc=irons

then it works.

Is it an Acegi or a ApacheDS problem ? 


Best regards,
Flavio

-----Messaggio originale-----
Da: Emmanuel Lecharny [mailto:elecharny@gmail.com ]
Inviato: lunedì 19 marzo 2007 23.19
A: Apache Directory Developers List 
Oggetto: [Attributes manipulation] How to manipulate attributes inside the
server

Hi,

We have some serious issues in the server with Attributes manipulation.
This mail is intended to avoid as much as possible potential breakage 
and bugs, by giving explicit rules of thumb about the way we should
handle attributes.

First, we will focusing on ADS 1.5, because ADS 1.0.1 is already out.
Second, this mail applies only to in-server attribute manipulations, and 
does not cover clients or tests.

Ok, now, let's get deep into the, well, mud.

1) Introduction, terminology
We have implemented Attribute and Attributes, which are
javax.naming.directory interfaces 
(http://72.5.124.55/j2se/1.5.0/docs/api/javax/naming/directory/Attribute.htm

l
and
http://72.5.124.55/j2se/1.5.0/docs/api/javax/naming/directory/Attributes.htm
l).
The associated classes in the server are :
org.apache.directory.shared.ldap.message.AttributeImpl
and
org.apache.directory.shared.ldap.message.AttributesImpl 

An Attributes can contain many Attribute. Each Attribute contains a key
(the attribute type) and many values.
As we are in the Ldap World, the Attributes are associated with an Entry.

2) Attribute types 
Each Attribute has a key which is unique within an Attributes (Entry).
This key is *case insensitive*. It means that "cn" is equivalent to "CN"
or "Cn".
---> First rule : _always use a lowercased attribute name_ 
This key is not necessarily the best key to identify an attribute.
Internally, we should *always* use the associated OID (we have a
relation between an OID and an attribute type : An attributeType
*always* has a unique OID, when an OID can be associated with more than 
one attributeType)
--> Second rule : _when possible, use the OID instead of any other
textual name_

What does it mean, in the real world ? Simply, use the OID.

3) Potential problems
The user don't want to receive OIDs when he launch a search. OIDs are 
good for serrvers, not for clients...
Generally, a client ask for a list of attributes as a result of a
search. This list should be returned as it has been submitted :
let's assume a client has asked for SURNAME, we should not return an 
entry like 2.5.4.4=nerd, but something like SURNAME=nerd

---> Third rule : _return what the client is asking for, not what the
server is used to manipulate_

Another problem is that we might have to find a specific value of an 
attribute. For instance, we may look for the 'subschema' value in the
'objectClass' attribute. We have MatchingRules to compare two values.
Let's suppose we are dealing with the objectClass attributeType : the 
values should be compared case insensitive. PhoneNumber should be
compared after having remove any inner space. And so on. Each
attributeType is associated with an Equality Matching Rule which is to
be used to process comparizons. This leads to CN == cn == cN == Cn, with 
the ObjectClass equality matching rule.

An helper class contains two methods to help dealing with those
attributeTypes : AttributeUtils.
Three methods has been written :
- containsAnyValues( Attribute, Object[], AttributeType ) : check that 
an attribute contains at least one of the given values
- containsValue( Attribute, Object, AttributeType ) : check that the
attributes contains the given value
- containsValueCaseIgnore( Attribute, Object ) : special case where we 
check that the value is contained by the attribute, the case sensitivity
being desabled.

For method 1 and 2, the attributeType is used to call the associated
comparator.

---> Forth rule : When comparing two attribute values, always use the 
AttributeUtils class, and use the correct method.

Ok, that's all for now, I hope that this little reminder will help to
build a better server ...

Emmanuel

PS: I think this mail deserves to be put into confluence, but tonite, 
I'm too lazy ...








-- 
Cordialement,
Emmanuel Lécharny
www.iktek.com 




Mime
View raw message