directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: R: [Attributes manipulation] How to manipulate attributes inside the server
Date Tue, 20 Mar 2007 17:41:12 GMT
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