OpenSAML Velocity templates for POST etc. responses

[Cantor, Scott]

On 1/3/13 2:50 PM, "Michael A Grady" <mgrady at unicon.net> wrote:

>Carnegie Mellon came up with the approach of using Google Analytics to
>track stats on the use of their IdP. The basic approach being to embed
>the Google Analytics tracking code into the Velocity templates used for
>POSTing back the responses. And I've been considering how one could
>package that into the OpenSAML distribution as an optional thing that an
>institution could choose to use.

I would not be in favor of putting anything like that into the OpenSAML
distribution. I am strongly in favor of making it easier to customize the
templates, though I don't yet know how that's going to go for sure.

>Now I know that one could create one additional JAR file that just has
>those four (4) modified Velocity templates in them, each with a slightly
>different name than the originals, and then "wire in their use" by
>changing the appropriate config in the "internal.xml" file.

No, that's not advisable. It's best to avoid touching internal.xml.

The way you override the templates is just by dropping replacement copies
with the same names into WEB-INF/classes/templates and then doing the
install. The downside is you have to remember to copy them into any new
source tree across upgrades, but it's not a big deal to have that tracked
locally in some upgrade docs.

You don't need to change the names. The local copy takes precedence over
the jar copy.

>- add the GA accountId as another constructor arg in "internal.xml"
>(after the templateId), and pick that up in the encoder and put it into
>the Velocity context, where the template can get it from. This seems
>easiest if it works, because you'd need to be modifying the
>"internal.xml" file anyways to specify the templateId to use.

No, see above.

> - use the #include Velocity script element to read in a file that has
>the one line that specifies GA accountId. But I'm not sure if that
>directive will work in the context of the JAR file packaging.

The documentation says something about TEMPLATE_ROOT. I don't see how that
applies to the classloader input source it's using, but you could try it
and see.

There's no question those files are coming out of the jar and into the
file system for V3, at which point this is all moot, it's just a simple
local change. If the include trick did happen to work, I'm not averse to
having us embed an #include that pulls in an empty file from the jar that
one would override as above in WEB-INF (but you'd only have to modify that
one file).

>Or is there some other better approach? A way that one could distribute
>that one new JAR file, with the four modified Velocity templates, and
>have the GA accountId externally specified/dynamically picked up?

Can't use a jar, that much I know. The only way to override the existing
jar predictably is with the copy in WEB-INF.

The other way to think about it is some kind of pluggable injection of
properties into the template context that the code creates when it
processes those templates.

-- Scott