You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Alex Karasulu (JIRA)" <di...@incubator.apache.org> on 2005/10/19 03:45:44 UTC
[jira] Created: (DIRLDAP-62) [ACIITemParser] Position of terms in optional ASN.1 elements should not matter
[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
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRLDAP-62) [ACIITemParser] Position of terms in optional ASN.1 elements should not matter
Posted by "Ersin Er (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-62?page=comments#action_12355736 ]
Ersin Er commented on DIRLDAP-62:
---------------------------------
It's a fully flexible grammar now and ready for the release.
> [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
>
> 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.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DIRSERVER-232) [ACIITemParser] Position of terms in
optional ASN.1 elements should not matter
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-232?page=all ]
Alex Karasulu closed DIRSERVER-232.
-----------------------------------
fixed and confirmed
> [ACIITemParser] Position of terms in optional ASN.1 elements should not matter
> ------------------------------------------------------------------------------
>
> Key: DIRSERVER-232
> URL: http://issues.apache.org/jira/browse/DIRSERVER-232
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Affects Versions: pre-1.0
> Reporter: Alex Karasulu
> Assigned To: Ersin Er
> Fix For: pre-1.0
>
>
> 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.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DIRLDAP-62) [ACIITemParser] Position of terms in optional ASN.1 elements should not matter
Posted by "Ersin Er (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-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 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.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRLDAP-62) [ACIITemParser] Position of terms in optional ASN.1 elements should not matter
Posted by "Ersin Er (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-62?page=comments#action_12332450 ]
Ersin Er commented on DIRLDAP-62:
---------------------------------
It's really better to provide a more flexible grammar for the end user. As Emmanuel said, this will also simplify the grammar for this case. For grammar parts that are composed of optional elements, we'll need to check that each element is used only once and for the parts that are composed of non-optional elements, we'll need to check that each element is exactly used once. So what I think now is that it's not that hard to implement. I'll do it.
> [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
>
> 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.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DIRLDAP-62) [ACIITemParser] Position of terms in optional ASN.1 elements should not matter
Posted by "Emmanuel Lecharny (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-62?page=comments#action_12332432 ]
Emmanuel Lecharny commented on DIRLDAP-62:
------------------------------------------
being able to enter those names in any order is not a big deal. Further more, it will simplify the grammar.
The only tricky thing to control is that a name is used only once. Again, not a big deal, has we can use a HashMap to store each name already used.
In the antlr grammar, we have 12 rules than can be concatenated in only two rules.
So let's do it !
> [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
>
> 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.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DIRLDAP-62) [ACIITemParser] Position of terms in optional ASN.1 elements should not matter
Posted by "Alex Karasulu (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIRLDAP-62?page=all ]
Alex Karasulu reassigned DIRLDAP-62:
------------------------------------
Assign To: Ersin Er
Perhaps Ersin you can provide an assessment of how much an effort it would be to not have position factor into the terms of the ACI. Or perhaps it might not be a good idea to do this so let me know WYT. Thanks.
> [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
>
> 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.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira