Attribute release consent failing (sometimes)

[Tom Zeller]

> it seems the n.s.i.consent.flow.impl.ExtractConsent=DEBUG setting just
> gives me an entry within idp-process.log that is otherwise already
> present in idp-consent-audit.log

With n.s.i.consent.flow.impl.ExtractConsent at debug, there should be
lines in idp-process.log that look like :

DEBUG [net.shibboleth.idp.consent.flow.impl.ExtractConsent:81] -
Profile Action ExtractConsent: Extracted consent ids
'[eduPersonPrincipalName, eduPersonScopedAffiliation, mail, uid]' from
request parameter '_shib_idp_consentIds'

DEBUG [net.shibboleth.idp.consent.flow.impl.ExtractConsent:93] -
Profile Action ExtractConsent: Consent context
'ConsentContext{previousConsents={},
chosenConsents={eduPersonPrincipalName=Consent{id=eduPersonPrincipalName,
value=null, isApproved=true},
eduPersonScopedAffiliation=Consent{id=eduPersonScopedAffiliation,
value=null, isApproved=true}, mail=Consent{id=mail, value=null,
isApproved=true}, uid=Consent{id=uid, value=null, isApproved=true}}}'

These lines list the attributes returned (extracted) from the browser.
If you see isApproved=false in the second line, then that indicates an
issue with the browser.

> If nothing helps, I need to try idp.consent.compareValues=false

Actually, I think I misspoke earlier. The only code that sets
isApproved(false) is in the ExtractConsent action (logged above). Even
if values are not compared "correctly", the
AttributeReleaseConsentFunction uses the previous consent value.

I'm curious how isApproved was ever set to false.

Tom