Unfortunately I'm dealing with an upstream library that needs a WebTarget
not a Request. I'll investigate sending them a PR to allow both.
My latest gross-hack is to pass it through the client's config property, it
works, but I'm wondering if there's some awful consequences I'm not
considering?
public void doMyThing(MyPrincipalClass auth) {
WebTarget wt = jerseyClient.target("the twirp
url").build()).property("authHack", auth);
//
}
Then in the filter I can grab it again:
final Collection<String> configPropertyNames =
requestContext.getConfiguration().getPropertyNames();
if (configPropertyNames.contains("authHack")) {
AuthenticationContext auth = (AuthenticationContext)
requestContext.getConfiguration().getProperty("authHack");
requestContext.getHeaders().add(JWT_HEADER_NAME, auth.getHeader());
}
This feels kind of messy, but appears to function as designed and will be a
decent enough standin while I'm trying to get the upstream changes made.
On Friday, 26 October 2018 10:46:53 UTC+13, Steve Kradel wrote:
>
> 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.
