Filters don't introduce threading problems per se, so you may have some
other things going on.
Anyhow, try a simpler alternative to a filter:
client.target("some uri").request().header(JWT_HEADER_NAME,
auth.getHeader()).post(someEntity)
On Thursday, October 25, 2018 at 5:35:25 PM UTC-4, Michael Koziarski wrote:
>
> Our current workaround is to explicitly pass the value around, so I'm
> happy going back that way. It's mostly working fine, except I have to
> register a filter at runtime:
>
> public void doMyThing(MyPrincipalClass auth) {
> WebTarget wt = jerseyClient.target("the twirp url").build()).register(new
> ClientRequestFilter() {
> @Override
> public void filter(ClientRequestContext requestContext) throws
> IOException {
> requestContext.getHeaders().add(JWT_HEADER_NAME, auth.getHeader());
> }
> });
> }
>
> Registering that filter at runtime causes the client's stack of filters
> and what not to be cloned and appears to have a concurrency bug which leads
> to sporadic errors.
>
> I need to register a filter rather than just inject the header to the
> Invocation so I can pass a WebTarget (with associated headers) to the Twirp
> library we're using.
>
> So I can see that ClientRequestContext has a 'getProperty', is there a way
> for me to pass set that property on a given WebTarget?
>
>
> On Friday, 26 October 2018 09:36:13 UTC+13, Steve Kradel wrote:
>>
>> You'll want to register a filter on the Dropwizard/Jersey Client object
>> (not environment.jersey() which is the "server"). Actually tracking the
>> client's security context can be a little tricky--use a ThreadLocal as you
>> mentioned, or, to preserve sanity in potentially async/multithreaded cases,
>> pass around the Principal as a value and wire to each outgoing request as
>> needed. FWIW I am not a fan of ThreadLocal for security properties.
>>
>> On Wednesday, October 24, 2018 at 10:56:50 PM UTC-4, Michael Koziarski
>> wrote:
>>>
>>> Hi,
>>>
>>> We have a dropwizard 1.1 service which authenticates inbound requests
>>> using dropwizard-auth and I'm hoping to get access to that Principal in
>>> classes which aren't resources. The tl;dr for why, is we have our own
>>> internal authentication mechanism which retrieves a token from an http
>>> header and needs to pass a variant of that header back out on any outbound
>>> requests it makes to other services. Unfortunately I basically have no
>>> idea how the jersey injection works... At all.
>>>
>>> What I'm *hoping* to be able to do is register a ClientRequestFilter
>>> which will thread the Principal from the inbound HttpServletRequest through
>>> to the outbound jersey client request. Something like:
>>>
>>> ```
>>> public class AuthenticationContextInjectionFilter implements
>>> ClientRequestFilter {
>>> public static final String OUTBOUND_HEADER_NAME = "Some-Thing";
>>>
>>> @Inject // Or is it @Context?
>>> private Provider<MyPrincipalClass> principal; // Have also tried
>>> Provider<Principal>
>>>
>>> @Override
>>> public void filter(ClientRequestContext requestContext) throws
>>> IOException {
>>> final MyPrincipalClass principalVal = this.principal.get();
>>> requestContext.getHeaders().add(OUTBOUND_HEADER_NAME,
>>> principalVal.getHeader());
>>> }
>>> }
>>>
>>> // and in my Application
>>>
>>> environment.jersey().register(AuthenticationContextInjectionFilter.class);
>>> ```
>>>
>>> However, it's basically always null so however jersey's injection works
>>> is clearly not the way I think it works.
>>>
>>> Is it possible to achieve what I'm trying to do here? I can probably
>>> biff the value into a ThreadLocal to work around this, but that feels a
>>> little like i'm surrendering. Is there some introductory documentation I
>>> could read on this stuff?
>>>
>>>
>>>
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
