ECMA to access SubjectCanonicalizationContext in Resolver

Cantor, Scott cantor.2 at osu.edu
Tue Nov 10 22:47:29 EST 2015


On 11/10/15, 10:35 PM, "dev on behalf of Cantor, Scott" <dev-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:



>On 11/10/15, 10:21 PM, "dev on behalf of Michael A Grady" <dev-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:
>
>>The one remaining question would be "is there any simple activation condition I could use to get this special Data Connector (DC) and this attribute definition to only run at c14n time"? I.e. so the normal resolution step doesn't try to run it? Because I needed to account for that in the script, in order to ensure that there was at least one "empty" value for the attribute, so the associated DC didn't error out when it tried to resolve rawUsername.get(0). Maybe there is a better way to handle the latter?
>
>A data connector shouldn't need to error out, you can tell them to treat no results as a normal conditon. But that should be the default. How is it erroring out?

What V2 used to do with Velocity expressions that didn't match anything provided was just echo them as strings, so you'd get $rawUsername.get(0) in your LDAP search, which doesn't match anything. Maybe not ideal, but it does what you'd expect.

If it's not doing that, the behavior changed, but you probably could work around it with a more complex Velocity macro with a conditional expression testing for something. But I'd still like to understand what it's doing.

-- Scott



More information about the dev mailing list