We are still in the process of moving the last few applications from DSEE to OUD 11g so the DSEE 6.3 directory can be decommissioned. Just two to go! But the application, when pointed to the OUD servers, gets “Unable to cast object of type ‘System.Byte[]’ to type ‘System.String'” when retrieving values for a few of our DirectoryString syntax custom schema.
This code snippet works fine with DSEE 6.3.
string strUserGivenName = (String)searchResult.Properties["givenName"][0]; string strUserSurame = (String)searchResult.Properties["sn"][0]; string strSupervisorFirstName = (String)searchResult.Properties["positionmanagernamefirst"][0]; string strSupervisorLastName = (String)searchResult.Properties["positionmanagernamelast"][0];
Direct the connection to the OUD 11g servers, and an error is returned.
The attributes use the same syntax – DirectoryString, OID 1.3.6.1.4.1.1466.115.121.1.15.
00-core.ldif:attributeTypes: ( 2.5.4.41 NAME ‘name’ EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} X-ORIGIN ‘RFC 4519’ )
00-core.ldif:attributeTypes: ( 2.5.4.4 NAME ( ‘sn’ ‘surname’ ) SUP name X-ORIGIN ‘RFC 4519’ )
00-core.ldif:attributeTypes: ( 2.5.4.42 NAME ‘givenName’ SUP name X-ORIGIN ‘RFC 4519’ )
99-user.ldif:attributeTypes: ( positionManagerNameMI-oid NAME ‘positionmanagernamemi’ DESC ‘User Defined Attribute’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN ‘user defined’ )
99-user.ldif:attributeTypes: ( positionManagerNameFirst-oid NAME ‘positionmanagernamefirst’ DESC ‘User Defined Attribute’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN ‘user defined’ )
99-user.ldif:attributeTypes: ( positionManagerNameLast-oid NAME ‘positionmanagernamelast’ DESC ‘User Defined Attribute’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN ‘user defined’ )
I’ve put together a quick check to see if the returned value is an array, and if it is then get a string from the decoded byte array.
string strUserGivenName = (String)searchResult.Properties["givenName"][0]; string strUserSurame = (String)searchResult.Properties["sn"][0]; string strSupervisorFirstName = ""; string strSupervisorLastName = ""; if (searchResult.Properties["positionmanagernamefirst"][0].GetType().IsArray){ strSupervisorFirstName = System.Text.Encoding.UTF8.GetString((byte[])searchResult.Properties["positionmanagernamefirst"][0]); } else{ strSupervisorFirstName = searchResult.Properties["positionmanagernamefirst"][0].ToString(); } if (searchResult.Properties["positionmanagernamelast"][0].GetType().IsArray){ strSupervisorLastName = System.Text.Encoding.UTF8.GetString((byte[])searchResult.Properties["positionmanagernamelast"][0]); } else{ strSupervisorLastName = searchResult.Properties["positionmanagernamelast"][0].ToString(); }
Voila
The outstanding question is if we need to wrap *all* DirectoryString syntax attributes in this check to be safe or if there’s a reason core schema attributes like givenName and sn are being returned as strings whilst our add-on schema attributes have been encoded.
Hi Lisa,
We’re you able to find a solution for above problem? What was the fix as I am also facing similar issue.
Thanks,
Naveen
Hi Naveen, I’d opened a case with Oracle but didn’t get any explanation of the logic determining when values would be UTF-8 encoded. The support engineer repeatedly told me that having a UTF-8 character in an attribute value would produce a UTF-8 encoded response when retrieving that attribute … but my account only contains basic ASCII characters, so that explanation wasn’t applicable. Since I was seeing the problem in custom code, I just added the if condition to differentiate between encoded and non-encoded values and just accepted that we’d be getting encoded values in some instances. Sorry I can’t be more help!
Happy Friday!
–L