Apache Directory Project - [jira] Resolved: (DIRLDAP-62) [ACIITemParser] Position of terms in optional ASN.1 elem

This is Interesting: Free IT Magazines  
Home > Archive > Apache Directory Project > October 2005 > [jira] Resolved: (DIRLDAP-62) [ACIITemParser] Position of terms in optional ASN.1 elem





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author [jira] Resolved: (DIRLDAP-62) [ACIITemParser] Position of terms in optional ASN.1 elem
Ersin Er (JIRA)

2005-10-25, 7:45 am

[ http://issues.apache.org/jira/brows...DAP-62?page=all ]

Ersin Er resolved DIRLDAP-62:
-----------------------------

Fix Version: 0.9.3
Resolution: Fixed

> [ACIITemParser] Position of terms in optional ASN.1 elements should not matter
> ------------------------------------------------------------------------------
>
> Key: DIRLDAP-62
> URL: http://issues.apache.org/jira/browse/DIRLDAP-62
> Project: Directory LDAP
> Type: Improvement
> Components: Common
> Reporter: Alex Karasulu
> Assignee: Ersin Er
> Fix For: 0.9.3


>
> 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 stri

ct 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.
>


--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira


Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com