Performing conditional gets with the metadata aggregator
Wessel, Keith
kwessel at illinois.edu
Fri Mar 17 14:47:19 EDT 2017
Hi, Ian,
Yes, you're correct; we're just using a DOMResource. I'm somewhat relieved to know that I wasn't missing something obvious here.
Here's the (quite standard, I suspect) snippet from my configuration:
<bean id="readIncommonMetadta" class="net.shibboleth.metadata.dom.DOMResourceSourceStage"
p:id="readIncommonMetadta" p:parserPool-ref="parserPool">
<property name="DOMResource">
<bean class="net.shibboleth.ext.spring.resource.FileBackedHTTPResource" >
<constructor-arg ref="incommonMdBackingFile" />
<constructor-arg ref="httpClient" />
<constructor-arg ref="incommonMdUrl" />
</bean>
</property>
</bean>
I'd be happy to work with you, here or in the enhancement request on Github, to figure this one out. As our discovery service (using SwitchWAYF which can only take one metadata source) needs metadata from multiple sources including a hand full of SPs in InCommon, the MDA has been great for us pulling together the needed metadata. But I hate pulling down the InCommon aggregate multiple times a day. So, I'd love to help our situation while helping others.
Keith
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Ian Young
Sent: Friday, March 17, 2017 11:45 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: Performing conditional gets with the metadata aggregator
On 17 Mar 2017, at 14:30, Wessel, Keith <kwessel at illinois.edu> wrote:
Wondered how one would configure the MDA to do a conditional get of metadata in a bean using the file backed HTTP resource class. I'm a couple versions behind with this software (0.9.1), so if this is the default in newer versions, that'd be great. Otherwise, it seems that the default is to not do a conditional get, and my instance is pulling down the InCommon metadata every five minutes (ugh).
There's no change in later versions of the MDA. Assuming you are using DOMResourceSourceStage to pick up your metadata, the behaviour comes down to the HTTPResource you construct for your DOMResource. One of the constructor arguments is an HTTP client, which in turn probably comes from HttpClientBuilder from java-support. The default behaviour at that level really has to be non-cacheing, so that the client doesn't have to find somewhere to cache what might be a very large document.
However, at that level there are also FileCachingHttpClientBuilder and InMemoryCachingHttpClientBuilder classes you could use instead to get the desired behaviour.
You'll gather this is one of the things I think can be done at least in principle but which I haven't had time to try out and generate an example for in practice (see for example https://github.com/iay/mdq-server-docker/issues/7). I'd be happy to work on this with you so that we can write such an example for the general benefit.
Cheers,
-- Ian
More information about the users
mailing list