
|
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 » |
| There are no subversion log entries for this issue yet.
|
|