Anonymous_User Absent Member.
Absent Member.

Re: Resource request activity and resource with trailing space inCN

On 2014-03-24 13:55, Steven Williams wrote:
> On 03/19/2014 09:33 AM, alekz wrote:
>> On 2014-03-19 14:12, Steven Williams wrote:
>>> On 03/19/2014 08:50 AM, Steven Williams wrote:
>>>> On 03/19/2014 08:17 AM, Geoffrey Carman wrote:
>>>>> On 3/19/2014 8:13 AM, Geoffrey Carman wrote:
>>>>>>
>>>>>>>> The actual CN value is 64 characters including the space at the
>>>>>>>> end.
>>>>>>>> This is the anonymized value. Without the '.
>>>>>>>>
>>>>>>>> 'CN_Admin 12345678 iiiiiiiii_OU_Administrativa Grupper_OU_Lokala'
>>>>>>>>
>>>>>>> Greetings,
>>>>>>> I have tried a number of different ways and can not get an
>>>>>>> object to
>>>>>>> be created in eDirectory with a trailing space. I will see if I can
>>>>>>> create an set-up that will allow RMA to create a similar cn.
>>>>>>
>>>>>> Easy to create an object with a trailing space.
>>>>>>
>>>>>> Designer will do it. Name a policy or something with a trailing
>>>>>> space.
>>>>>> (It won't compare properly after that, due an eDir vagary).
>>>>>>
>>>>>> LDAP, using an LDIF< base64 encode the value, and use a ::
>>>>>> notation on
>>>>>> the data line to indicate it is encoded.
>>>>>>
>>>>>> Console1 can do it.
>>>>>>
>>>>>> eDir has a funny behavior around leading and trailing spaces in
>>>>>> Naming
>>>>>> attributes (cn=, ou=, whatever your naming attribute it).
>>>>>>
>>>>>> It will consider "Geoffrey " the same as "Geoffrey", "Geoffrey "
>>>>>> and
>>>>>> everywhere in between. Same for leading spaces. And I believe it
>>>>>> will
>>>>>> sort of ignore leading and trailing spaces when doing
>>>>>> searches/compares.
>>>>>> That is, "cn=Geoffrey" and "cn=Geoffrey " are basically the same
>>>>>> thing from eDir's perspective. It has been this way for decades now.
>>>>>>
>>>>>> This manifests in Designer if you create an object with a
>>>>>> leading/trailing space (Though I have only every tried with trailing
>>>>>> space (inadvertantly)) it will push it out. But on every compare it
>>>>>> will recognize that the Designer side object does not match the eDir
>>>>>> object, since Designer is remembering the trailing space and eDir is
>>>>>> sort of ignoring it.
>>>>>
>>>>> Now that I think about it, I have no idea what eDir does, if the field
>>>>> length is 64 chars, and you have a 63 char string, followed by 3
>>>>> spaces?
>>>>> Probably does not allow you to create it at create/rename time.
>>>>>
>>>>>
>>>> Greetings,
>>>> Thank you Geoffrey. Designer was the ticket. You do not need
>>>> it to
>>>> be 60+ characters. I created a resource: 'End with Space ' and
>>>> deployed from Designer.
>>>>
>>>> When I went to the Assignments tab of the Resource in the User
>>>> Application, I received the following error:
>>>>
>>>> Error loading resource assignments: Resource with DN = [cn=End with
>>>> Space\ ,cn=ResourceDefs,cn=RoleConfig,cn=AppConfig,cn=User Application
>>>> Driver,cn=driverset1,o=system ] does not exist.
>>>>
>>>>
>>>> I will investigate this a bit more to determine if the bug should go
>>>> against RBPM or Designer & RMA.
>>>>
>>> Greetings,
>>> I am not seeing a problem using the Resource Request Activity in a
>>> workflow.
>>>
>>> Here is the value in the Resource field:
>>>
>>> 'CN=End with Space,CN=ResourceDefs,CN=RoleConfig,CN=AppConfig,CN=User
>>> Application Driver,CN=driverset1,O=system'
>>>
>>> The Resource does get assigned to the user.
>>>
>>> With that said, the Resource does not render 100% correctly on the Work
>>> Dashboard. In that the Display name of the Resource is not there. It
>>> is empty.
>>>
>>> Questions:
>>>
>>> 1) Are you mapping to the Resource directly or are you utilizing an
>>> Expression in the Resource Request Activity?
>>>
>>> 2) Is the Vault on Windows or Linux?
>>>
>>> 3) Is User Application on Windows or Linux?
>>>

>>
>>
>> 1) Expression, we are getting the resource DNs from a query in the form
>> which gives us 'CN=End with Space\ ,CN=ResourceDefs......'
>> Notice the '\ '.
>>
>> Something like this in a mapping activity:
>>
>> flowdata.targetresource:
>>
>> function getNextResource()
>> {
>> var nextResource = flowdata.get('addResources[' +
>> flowdata.get('dnCounter') + ']');
>> return nextResource;
>> };
>> getNextResource();
>>
>> 2) Linux, non-root
>>
>>
>> 3) Linux
>>

> Greetings,
> How are you creating the list for the end-users to select from in in
> the Workflow? Are you using a DAL Query to present a list of Resources?
> Are you showing a static list and then building the dn after?
> Understanding what your are doing is important here. From my earlier
> post, you can see that quoting the entire DN works. Also, for Roles the
> Expression Build creates it correctly.
>

The DN's are stored on an object in the directory in a custom attribute
that has the DN syntax.
We are using a query to read that attribute and present it to the users.

By removing the trailing space from the DN before using it in the
workflow the process works fine now.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Resource request activity and resource with trailing space inCN

>>> On 19.03.2014 at 13:13, Geoffrey
Carman<geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:

>>> The actual CN value is 64 characters including the space at the end.
>>> This is the anonymized value. Without the '.
>>>
>>> 'CN_Admin 12345678 iiiiiiiii_OU_Administrativa Grupper_OU_Lokala'
>>>

>> Greetings,
>> I have tried a number of different ways and can not get an object to


>> be created in eDirectory with a trailing space. I will see if I can
>> create an set‑up that will allow RMA to create a similar cn.

>
> Easy to create an object with a trailing space.
>
> Designer will do it. Name a policy or something with a trailing space.
> (It won't compare properly after that, due an eDir vagary).
>
> LDAP, using an LDIF< base64 encode the value, and use a :: notation on
> the data line to indicate it is encoded.
>
> Console1 can do it.
>
> eDir has a funny behavior around leading and trailing spaces in Naming
> attributes (cn=, ou=, whatever your naming attribute it).
>
> It will consider "Geoffrey " the same as "Geoffrey", "Geoffrey " and


>
> everywhere in between. Same for leading spaces. And I believe it will
> sort of ignore leading and trailing spaces when doing searches/compares.


>
> That is, "cn=Geoffrey" and "cn=Geoffrey " are basically the same
> thing from eDir's perspective. It has been this way for decades now.
>
> This manifests in Designer if you create an object with a
> leading/trailing space (Though I have only every tried with trailing
> space (inadvertantly)) it will push it out. But on every compare it
> will recognize that the Designer side object does not match the eDir
> object, since Designer is remembering the trailing space and eDir is
> sort of ignoring it.


That happens if you use straight string comparison methods on distinguished
names. There are string representations of DNs but inherently a DN is a
complex datatype with its own compare methods (aka matching rules).
All this was originally defined in X.500:

String matching rules
In the matching rules specified in 6.1.1 through 6.1.11, the following
spaces are regarded as not significant:
– leading spaces (i.e. those preceding the first character that is not a
space);
– trailing spaces (i.e. those following the last character that is not a
space);
– multiple consecutive spaces (these are taken as equivalent to a single
space character).
A string consisting entirely of spaces is equivalent to a string containing
exactly one space.
In the matching rules to which these apply, the strings to be matched shall
be matched as if the insignificant spaces were
not present in either string.

In addition, eDirectory also treats the underscore character "_" as a
space.

Norbert
0 Likes
Knowledge Partner
Knowledge Partner

Re: Resource request activity and resource with trailing space inCN

>> Easy to create an object with a trailing space.
>>
>> Designer will do it. Name a policy or something with a trailing space.
>> (It won't compare properly after that, due an eDir vagary).
>>
>> LDAP, using an LDIF< base64 encode the value, and use a :: notation on
>> the data line to indicate it is encoded.
>>
>> Console1 can do it.
>>
>> eDir has a funny behavior around leading and trailing spaces in Naming
>> attributes (cn=, ou=, whatever your naming attribute it).
>>
>> It will consider "Geoffrey " the same as "Geoffrey", "Geoffrey " and

>
>>
>> everywhere in between. Same for leading spaces. And I believe it will
>> sort of ignore leading and trailing spaces when doing searches/compares.

>
>>
>> That is, "cn=Geoffrey" and "cn=Geoffrey " are basically the same
>> thing from eDir's perspective. It has been this way for decades now.
>>
>> This manifests in Designer if you create an object with a
>> leading/trailing space (Though I have only every tried with trailing
>> space (inadvertantly)) it will push it out. But on every compare it
>> will recognize that the Designer side object does not match the eDir
>> object, since Designer is remembering the trailing space and eDir is
>> sort of ignoring it.

>
> That happens if you use straight string comparison methods on distinguished
> names. There are string representations of DNs but inherently a DN is a
> complex datatype with its own compare methods (aka matching rules).
> All this was originally defined in X.500:


Neat! I always wondered at the origin of this behavior. So working as
designed, and just don't do dumb things with spaces in naming
attributes! 🙂

> String matching rules
> In the matching rules specified in 6.1.1 through 6.1.11, the following
> spaces are regarded as not significant:
> – leading spaces (i.e. those preceding the first character that is not a
> space);
> – trailing spaces (i.e. those following the last character that is not a
> space);
> – multiple consecutive spaces (these are taken as equivalent to a single
> space character).
> A string consisting entirely of spaces is equivalent to a string containing
> exactly one space.
> In the matching rules to which these apply, the strings to be matched shall
> be matched as if the insignificant spaces were
> not present in either string.
>
> In addition, eDirectory also treats the underscore character "_" as a
> space.



I forgot about underscore but that is a good point as well.

Another funny schema item... i forget the attribute and the syntax now,
but we ran into an attr in use in a Sun Directory where it was defined
as Directory String, but eDir followed X500 and used the special syntax
it required that basically said, any normal string character is legal,
except a colon or semi colon. And they had been using a colon as a
delimiter in the string.

That was fun to figure out! 🙂

> Norbert
>


0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.