v3 consent to attribute release : model terms-of-use as attribute ?

Tom Zeller tzeller at dragonacea.biz
Tue Sep 30 23:28:59 EDT 2014


> So, roughly, say you have a webflow configured at e.g.,
> /profile/interceptor/tou. It requires that the InterceptorFlowDescriptor
> type be a subclass, TermsInterceptorFlowDescriptor, and the token I speak
> of above is a field you populate in the config into that descriptor object.
>
> Then the flow itself looks at the InterceptorContext to get the
> descriptor, tests and casts down to get the token, and maps that to the
> text with the MessageSource interface.
>
> That was my general idea. One flow, easy to configure as many times as
> desired using interceptors.xml or whatever we call it, just a couple of
> things to populate to get it working.

That's a bit different than what I was doing, because I was thinking I
would model TOU as attribute consent, so I had added a ConsentContext
as a third parameter to the interceptor do*Execute() methods in an
AbstractConsentAction. If TOU is not modeled as attribute consent,
then I either needed to add yet another (a fourth !) context parameter
for either the AttributeConsentContext or TermsOfUseContext (because
those contexts hold different data, either the attributes to be
processed or the TOU itself) or test and cast down as you suggested.
Adding those context parameters obviously doesn't scale, as I just
found out, so I am doing a bit of refactoring, checking the type of
profile interceptor context in the top-level abstract actions in the
two consent flows. Your suggestion is better than what I was doing,
but at the time it was a coin toss between casting the context or
passing the consent context as a method parameter, as I was hoping for
a single ConsentContext, oh well.

I'll try to commit what I've got after refactoring so you can take a look.

Briefly, there is a single n.s.i.consent.Consent object which can be
serialized and stored, and extracted from a form request by a
n.s.i.consent.flow.ExtractConsent action. There is one
ConsentSerializer, ConsentResult, StorageKeyLookupFunction and
FlowIdStorageContextLookupFunction.

Storage related actions common to both TOU and consent flows are in
the n.s.i.consent.flow.storage package, ReadConsentFromStorage,
RevokeConsent, and CreateResult (whose result is then written to
storage by the interceptor write action).

Actions specific to attribute consent are in n.s.i.consent.flow.ar,
and are InitializeAttributeConsentContext, IsAttributeConsentRequired,
ProcessAttributes (whitelist/blacklist/ordering),
CreateAttributeConsentChoices (to populate the view form), and
ReleaseAttributes.

Actions specific to TOU are in n.s.i.consent.flow.tou and are
InitializeTermsOfUseContext, IsTermsOfUseConsentRequired, and
CreateTermsOfUseChoice (to populate the view form).

The attribute release, per-attribute release, and TOU flows were
working earlier today, but I'll need to refactor. The views are ugly
and I have few tests and I'm missing a few configuration toggles.


More information about the dev mailing list