Backslash being stripped out of user name
Hi,
When I deploy an application with a user role mapping the \ that is within the username is stripped out. The property is as below:
options.multi.one.MapRolesToUsers=
However, when the application is deployed I end up with the user as below:
CN=Service
Account
AU,OCI
MDM
Client
Service,OU=AU,OU=Service
Accounts,OU=ANZ
Security
Objects,DC=oceaniatst,DC=corptst,DC=anz,DC=com
I've tried lots of combinations, like double \'s, to try and get around the issue but with no luck. Has anyone else been able to add a user role mapping with a user that includes a \ ? Any help would be greatly appreciated.
Cheers.
Des
When I deploy an application with a user role mapping the \ that is within the username is stripped out. The property is as below:
options.multi.one.MapRolesToUsers=
However, when the application is deployed I end up with the user as below:
CN=Service
Account
AU,OCI
MDM
Client
Service,OU=AU,OU=Service
Accounts,OU=ANZ
Security
Objects,DC=oceaniatst,DC=corptst,DC=anz,DC=com
I've tried lots of combinations, like double \'s, to try and get around the issue but with no luck. Has anyone else been able to add a user role mapping with a user that includes a \ ? Any help would be greatly appreciated.
Cheers.
Des
One answer
depending on how and where the value is used, you may have to use more than 2 backslashes.
for instance, if you're needing that value in a BF variable, 2 will be sufficient. If you need it available at the shell level 4 may be required. If you're using it inside of an adaptor, 8 may be required. Setting the nopreparse variable will reduce the number.
the amount of doubling of backslashes and dollar-signs depends on no-preparse, the architecture, the level at which the value is needed to be used, and whether or not the value is being used in an adaptor. Each value evaluation adds to the doubling required.
when I run upon something like this I'll usually add several "echo" lines to the step in question with in increasing number of backslashes or dollar signs. then check step-log output to get the right one. note that in some architectures '$$' evaluates to a numeric process ID. In your case with just backslashes, it will be much simpler.
no this is not optimal. But its what we have to work with at the moment.
for instance, if you're needing that value in a BF variable, 2 will be sufficient. If you need it available at the shell level 4 may be required. If you're using it inside of an adaptor, 8 may be required. Setting the nopreparse variable will reduce the number.
the amount of doubling of backslashes and dollar-signs depends on no-preparse, the architecture, the level at which the value is needed to be used, and whether or not the value is being used in an adaptor. Each value evaluation adds to the doubling required.
when I run upon something like this I'll usually add several "echo" lines to the step in question with in increasing number of backslashes or dollar signs. then check step-log output to get the right one. note that in some architectures '$$' evaluates to a numeric process ID. In your case with just backslashes, it will be much simpler.
no this is not optimal. But its what we have to work with at the moment.