Issue Details (XML | Word | Printable)

Key: DIRSERVER-232
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Ersin Er
Reporter: Alex Karasulu
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Directory ApacheDS

[ACIITemParser] Position of terms in optional ASN.1 elements should not matter

Created: 19/Oct/05 10:44 AM   Updated: 02/Oct/06 02:00 PM
Return to search
Component/s: ldap
Affects Version/s: pre-1.0
Fix Version/s: pre-1.0

Time Tracking:
Not Specified

Resolution Date: 25/Oct/05 08:50 PM


 Description  « Hide
The position of optional elements is relavent within the ACIItemParser. For example for ProtectedItems the position of optional elements are relevant so for example the following ACI whould bomb out:

                "{ " +
                "identificationTag \"searchAci\", " +
                "precedence 14, " +
                "authenticationLevel none, " +
                "itemOrUserFirst userFirst: { " +
                "userClasses { allUsers }, " +
                "userPermissions { { " +
                "protectedItems {allUserAttributeTypesAndValues, entry }, " +
                "grantsAndDenials { grantRead, grantReturnDN, grantBrowse } } } } }"

This however would succeed:

                "{ " +
                "identificationTag \"searchAci\", " +
                "precedence 14, " +
                "authenticationLevel none, " +
                "itemOrUserFirst userFirst: { " +
                "userClasses { allUsers }, " +
                "userPermissions { { " +
                "protectedItems {entry, allUserAttributeTypesAndValues }, " +
                "grantsAndDenials { grantRead, grantReturnDN, grantBrowse } } } } }"

The same holds for other constructs where a sequence of optional elements are expected. However this is a big problem. The user specifying the ACI must know what comes first, what comes second and so on in the ASN.1 description. This is just too strict of a constraint to place on users and will degrade the ease of use.

Really because we have names for each field order does not need to matter anymore.

I marked this as an improvement as opposed to a bug because the ASN.1 to ABNF translation was correct. It just is not the best thing to do.
 

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no subversion log entries for this issue yet.