
|
If you were logged in you would be able to see more operations.
|
|
|
| Resolution Date: |
25/Oct/05 08:50 PM
|
|
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.
|
|
Description
|
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.
|
Show » |
made changes - 19/Oct/05 10:46 AM
| Field |
Original Value |
New Value |
|
Assignee
|
|
Ersin Er
[ ersiner
]
|
made changes - 25/Oct/05 08:50 PM
|
Fix Version/s
|
|
0.9.3
[ 12310221
]
|
|
Resolution
|
|
Fixed
[ 1
]
|
|
Status
|
Open
[ 1
]
|
Resolved
[ 5
]
|
made changes - 07/Feb/06 02:41 PM
|
Type
|
Improvement
[ 4
]
|
Bug
[ 1
]
|
|
Key
|
DIRLDAP-62
|
DIRSERVER-232
|
|
Fix Version/s
|
|
pre-1.0
[ 12310782
]
|
|
Project
|
Directory LDAP
[ 10514
]
|
ApacheDS
[ 12310260
]
|
|
Component/s
|
Common
[ 11085
]
|
|
|
Fix Version/s
|
0.9.3
[ 12310221
]
|
|
|
Component/s
|
|
ldap
[ 12310715
]
|
|
Affects Version/s
|
|
pre-1.0
[ 12310782
]
|
made changes - 02/Oct/06 02:00 PM
|
Status
|
Resolved
[ 5
]
|
Closed
[ 6
]
|
|