attribute resolver issues after upgrade to v3

[Cantor, Scott]

On 8/14/15, 8:01 PM, "users on behalf of Robert A Basch" <users-bounces at shibboleth.net on behalf of rbasch at mit.edu> wrote:

>We found that we can avoid this error by removing all of the
>whitespace around the filters within the template, e.g.:

I always have had to do that in the TemplateAttributeDefinition, so it's a little weird that the LDAP one wasn't like that. It was probably inconsistent, but I have no idea whether it was documented/defined behavior or not. It wouldn't have been a deliberate change so it's either a bug or wasn't intended to work before or was a side effect of something else.

I don't really understand what it could have been stripping, it seems like it couldn't know what is significant. Perhaps it's a result of the change from vt-ldap to ldaptive and the old filters just worked there and don't work now. I don't know if you can log exactly what's being fed into the LDAP layer or not, might be interesting in the older IdP to see what actually gets passed in.

>In version 2, a test like the one in the above template works fine to
>detect a null value, but in version 3, the test fails, as the
>attribute tested apparently has an actual "NULL_VALUE" value.  With
>debug logging enabled, we see lines like this in the log:

It is true that the fix we settled on was to create an explicit value type for nulls (EmptyAttributeValue).

But isEmpty() should not have worked in V2. If it had, nulls embedded in columns of a result set wouldn't have "kept" their place in the grid of the result set across different attributes. That was the bug we had in V3 originally, the nulls were getting collapsed out.

This actually sounds like a bug in the V2 LDAP connector when it builds the Velocity context. If it was collapsing nulls, that would only work if the filter one was building wasn't depending on the fidelity of a result set spread across different attributes. Obviously not a common case since people are just using .get(0) most of the time and pulling only the first value of any attribute, but still not technically the right thing to do.

It's worth filing the issues, even if they aren't bugs or are related to other libraries or turn out to be bugs in V2, just for documenting the differences if they're unavoidable or intentional.

I would be particularly useful to know if that null collapsing behavior was true across other Velocity contexts in V2.

-- Scott