injecting a custom bean into a metadata filter

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

injecting a custom bean into a metadata filter

Tom Scavo
For Rod mainly---

I have two questions about the regex example you added to the
Predicate [1] metadata filter topic:

<bean id="the.Metadata.regexp.Pred"
class="net.shibboleth.utilities.java.support.logic.RegexPredicate"
c:_0="^.*sp1.*" />
<bean id="the.Metadata.Pred"
class="net.shibboleth.ext.spring.util.SpringExpressionPredicate"
        p:customObject-ref="the.Metadata.regexp.Pred"
        c:expression="#custom.apply(#input.getEntityID())" />

1. Where should I put the beans? Inside a metadata provider like any
other metadata filter?

2. Assuming the answer to the previous question is yes, why not
replace the second bean with

<MetadataFilter xsi:type="Predicate" direction="include"
removeEmptyEntitiesDescriptors="true">
    <ConditionScript customObjectRef="the.Metadata.regexp.Pred">
        <Script>
        <![CDATA[
            custom.apply(input.getEntityID());
        ]]>
        </Script>
    </ConditionScript>
</MetadataFilter>

Thanks,

Tom

[1] Predicate https://wiki.shibboleth.net/confluence/x/aAAzAQ
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: injecting a custom bean into a metadata filter

Rod Widdowson
> 1. Where should I put the beans? Inside a metadata provider like any
> other metadata filter?

Wherever suits you which out it into scope of the relevant Context.  I would put them in a file which was pointed to by
shibboleth.MetadataResolverResources  (which I think is what you mean when you say "Inside a metadata provider") since that way you
get reloadabilty of the important bit - see below for more about this.

 
> 2. Assuming the answer to the previous question is yes, why not
> replace the second bean with

[snip].  Many reasons, none of which have any importance to what is a "personal style" thing.

- A desire to see more documentation of the (phenomenally useful) SpringExpressionPredicate
- It's shorter
- A growing (and recent) disillusion with Oracle's inability to present a coherent story about JavaScript and hence a subliminal
desire to de-emphasise it.
- Because it was the way it happened.

As I say none of these reasons are really important.  Someone asked me to document how to do a regexp SP filter and so I just pulled
something (several somethings) together.  In the end it was for naught since its all 3.4 anyway and so a chocolate teapot for
someone who needs something for a current release.

To my mind, the real issue with either of these examples is the "functional inversion".  The thing that matters is the regexp, not
the injected predicate and that is not a natural way of reading that code.  Indeed I suppose I could say that putting what is
effectively function-free boiler plate into the custom syntax file, the JavaScript version draws attention away from the important
bit.  Someone says "Fix this _now_" to you and you don't want to waste time scanning MetadataResolver.xml to work what is happening,
you want to be end up at the bean file ASAP.   Maybe.

I should say that I am actively trying to work out a way to avoid this "functional inversion" in V3.4, but not really coming up with
any ideas.

R

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: injecting a custom bean into a metadata filter

Tom Scavo
On Wed, Jul 4, 2018 at 5:42 AM, Rod Widdowson <[hidden email]> wrote:
>> 1. Where should I put the beans? Inside a metadata provider like any
>> other metadata filter?
>
> Wherever suits you which out it into scope of the relevant Context.

Hmm, I'm still missing something I'm afraid.

> I would put them in a file which was pointed to by
> shibboleth.MetadataResolverResources  (which I think is what you mean when you say "Inside a metadata provider")

Every sample filter on that page is assumed to be a child element of
some parent <MetadataProvider>. (A <MetadataFilter> outside of that
context is like a fish out of water.) I'm trying to understand how the
beans are associated with a particular metadata provider.

Thanks,

Tom
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: injecting a custom bean into a metadata filter

Rod Widdowson
TL;DR - bung it in a separate file and point services.xml at it, just as you would any other native syntax.

> Hmm, I'm still missing something I'm afraid.

We do not allow custom syntax to be mixed with native syntax in V3.   There are several places where both native and custom syntax
have to be intermixed (eg[1]) and in support of that you can put the native syntax beans in several places[1].  Global.xml is an
obvious one but that suffers from lack of reloadability, so it would be more usual to bung it into a separate file [2] and point at
it from services.xml[3],[4].

You might want to skim over [5] again

[1] https://wiki.shibboleth.net/confluence/display/IDP30/PredicateConfiguration
[2] https://wiki.shibboleth.net/confluence/display/IDP30/SpringConfiguration
[3] https://wiki.shibboleth.net/confluence/display/IDP30/ReloadableServices
[4]
http://git.shibboleth.net/view/?p=java-identity-provider.git;a=blob;f=idp-conf/src/main/resources/conf/services.xml;h=e04ac8f0afceb2
d3afec9f0acbf2ed6c02a81a2c;hb=HEAD
[5] https://wiki.shibboleth.net/confluence/display/IDP30/Configuration#Configuration-ConfigurationOverviewsandReferences

--
To unsubscribe from this list send an email to [hidden email]