You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2007/04/21 15:59:15 UTC

[jira] Created: (DIRSERVER-906) Using the textual "entryACI" inside the server is dangerous and will lead to errors

Using the textual "entryACI" inside the server is dangerous and will lead to errors
-----------------------------------------------------------------------------------

                 Key: DIRSERVER-906
                 URL: https://issues.apache.org/jira/browse/DIRSERVER-906
             Project: Directory ApacheDS
          Issue Type: Bug
            Reporter: Emmanuel Lecharny


There are places in the server where we do some existance check against attributes such as "entryACI", "prescriptiveACI".

This is not good enough. If a client send en antry using "2.5.24.5" instead of "entryACI", the test will fail.

There are two way to fix it, it it will be costly :
1) during the normalization phase, *always* transform the attributeTypes to their OID counterpart so that comparizon is done with the OID
2) when looking for an attributeType, search for the OID in an Attributes, and nothing else.

Alternative would be to use the AttributeUtils.getAttribute(  Attributes, AttributeType ) method which return the attribute which type equals the one given as a parameter. There are 2 problems with this approach :
1) this method is buggy : if there is only one alias, then it is used, so you won't be able to find an Attribute using its OID ;)
2) it is slow, as you may have to find the AttributeType associated with an OID or a String first, and then you may loop through all the aliases.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (DIRSERVER-906) Using the textual "entryACI" inside the server is dangerous and will lead to errors

Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DIRSERVER-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny resolved DIRSERVER-906.
-----------------------------------------

    Resolution: Fixed
      Assignee: Emmanuel Lecharny

The "subentryACI" String has been moved to the SchemaConstants class. We are now using the constant in the server's code

> Using the textual "entryACI" inside the server is dangerous and will lead to errors
> -----------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-906
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-906
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 1.0.1, 1.5.0
>            Reporter: Emmanuel Lecharny
>         Assigned To: Emmanuel Lecharny
>             Fix For: 1.5.1
>
>
> There are places in the server where we do some existance check against attributes such as "entryACI", "prescriptiveACI".
> This is not good enough. If a client send en antry using "2.5.24.5" instead of "entryACI", the test will fail.
> There are two way to fix it, it it will be costly :
> 1) during the normalization phase, *always* transform the attributeTypes to their OID counterpart so that comparizon is done with the OID
> 2) when looking for an attributeType, search for the OID in an Attributes, and nothing else.
> Alternative would be to use the AttributeUtils.getAttribute(  Attributes, AttributeType ) method which return the attribute which type equals the one given as a parameter. There are 2 problems with this approach :
> 1) this method is buggy : if there is only one alias, then it is used, so you won't be able to find an Attribute using its OID ;)
> 2) it is slow, as you may have to find the AttributeType associated with an OID or a String first, and then you may loop through all the aliases.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (DIRSERVER-906) Using the textual "entryACI" inside the server is dangerous and will lead to errors

Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DIRSERVER-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny updated DIRSERVER-906:
----------------------------------------

        Fix Version/s: 1.5.1
    Affects Version/s: 1.5.0
                       1.0.1

> Using the textual "entryACI" inside the server is dangerous and will lead to errors
> -----------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-906
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-906
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 1.0.1, 1.5.0
>            Reporter: Emmanuel Lecharny
>             Fix For: 1.5.1
>
>
> There are places in the server where we do some existance check against attributes such as "entryACI", "prescriptiveACI".
> This is not good enough. If a client send en antry using "2.5.24.5" instead of "entryACI", the test will fail.
> There are two way to fix it, it it will be costly :
> 1) during the normalization phase, *always* transform the attributeTypes to their OID counterpart so that comparizon is done with the OID
> 2) when looking for an attributeType, search for the OID in an Attributes, and nothing else.
> Alternative would be to use the AttributeUtils.getAttribute(  Attributes, AttributeType ) method which return the attribute which type equals the one given as a parameter. There are 2 problems with this approach :
> 1) this method is buggy : if there is only one alias, then it is used, so you won't be able to find an Attribute using its OID ;)
> 2) it is slow, as you may have to find the AttributeType associated with an OID or a String first, and then you may loop through all the aliases.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (DIRSERVER-906) Using the textual "entryACI" inside the server is dangerous and will lead to errors

Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DIRSERVER-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Lecharny closed DIRSERVER-906.
---------------------------------------


Fixed in http://svn.apache.org/viewvc?view=rev&rev=534501

> Using the textual "entryACI" inside the server is dangerous and will lead to errors
> -----------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-906
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-906
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 1.0.1, 1.5.0
>            Reporter: Emmanuel Lecharny
>         Assigned To: Emmanuel Lecharny
>             Fix For: 1.5.1
>
>
> There are places in the server where we do some existance check against attributes such as "entryACI", "prescriptiveACI".
> This is not good enough. If a client send en antry using "2.5.24.5" instead of "entryACI", the test will fail.
> There are two way to fix it, it it will be costly :
> 1) during the normalization phase, *always* transform the attributeTypes to their OID counterpart so that comparizon is done with the OID
> 2) when looking for an attributeType, search for the OID in an Attributes, and nothing else.
> Alternative would be to use the AttributeUtils.getAttribute(  Attributes, AttributeType ) method which return the attribute which type equals the one given as a parameter. There are 2 problems with this approach :
> 1) this method is buggy : if there is only one alias, then it is used, so you won't be able to find an Attribute using its OID ;)
> 2) it is slow, as you may have to find the AttributeType associated with an OID or a String first, and then you may loop through all the aliases.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.