Re: [jersey-dev] debugging ClientRequestFilter with token

[Colin Williams <colin.williams.seattle@xxxxxxxxx>]

Thanks Jan.

The trivial way to expose the headers seemed to be netcat. But my
registered filter doesn't seem to produce anything in the requests.

E.G.

netcat -lp 8999
GET / HTTP/1.1
Host: localhost:8999
User-Agent: curl/7.64.1
Accept: */*
Authorization: Bearer d2a09f52-fd70-40be-a3d4-2d41cb549d5d

vs

netcat -lp 8999
GET / HTTP/1.1
Accept: application/json
User-Agent: Jersey/2.30.1 (HttpUrlConnection 1.8.0_272)
Host: localhost:8999
Connection: keep-alive


I found some reference to
System.setProperty("sun.net.http.allowRestrictedHeaders", "true"); . I
have set it but get above without the header. There is some slight
difference between the request with IE media type and Connection, but
I don't think I can attribute it to the missing header


On Wed, Dec 2, 2020 at 4:49 PM Jan Supol <jan.supol@xxxxxxxxxx> wrote:
>
> Hi,
>
> Using the client filter looks ok, but you can set the header to the
> request directly:
>
> ClientBuilder.newClient().target().request().header(HttpHeaders.AUTHORIZATION, ...)
>
> Debugging the headers is harder. It would be good to see what it comes to the server side, so you can use a @PreMatching filter and put the breakpoint there.
> If the server side is not JAX-RS endpoint, you can use WireShark (pcap) to sniff the HTTP transport.
> If you feel like debugging Jersey code, the good point is always ServerRuntime#process: https://github.com/eclipse-ee4j/jersey/blob/95c08d35331478ce47c4ae339c7f8542bf69fa22/core-server/src/main/java/org/glassfish/jersey/server/ServerRuntime.java#L200
>
> Try to compare what comes from CURL and what from the Jersey client to the server side.
>
> HTH,
> -- Jan
>
> On 02.12.2020 20:48, Colin Williams wrote:
> > Hello,
> >
> >
> > I’m trying to resolve an issue with using a token. Via curl I make a
> > request like
> >
> > curl -H 'Authorization: Bearer d2a09f52-fd70-40be-a3d4-2d41cb549d5d'
> > https://urldefense.com/v3/__https://service-endpoint/api/v1/namespaces/default/deployments__;!!GqivPVa7Brio!P3AaszBZQyjVXPwEj_K3UXwNElyb7EoDqyjUBcaJItsDxS84zXaysPe__Sl5dzGY$
> >
> > And the response is OK. Then I try to do the same using a
> > ClientRequestFilter and client. I receive an error code. I tried to
> > look in the debugger to see what the request header looks like. I
> > haven’t been able to find it, but maybe I should set the breakpoint
> > elsewhere.
> >
> > Then I’m looking for advice regarding what I might be doing wrong, or
> > where I might find the request header via debugger.
> >
> >
> > class BearerTokenFilter implements ClientRequestFilter {
> >    private final String bearerToken;
> >    public BearerTokenFilter(String bearerToken){
> >     this.bearerToken = bearerToken;
> > }
> >   public static final String FILTER_HEADER_KEY = "Authorization";
> >
> >    @Override
> >    public void filter(ClientRequestContext requestContext) throws IOException {
> >      String bearerTokenString = "Bearer " + bearerToken;
> >      requestContext.getHeaders().add(FILTER_HEADER_KEY,bearerTokenString);
> >    }
> >
> > builder.register(new
> > BearerTokenFilter(this.bearerToken)).build().property(HttpUrlConnectorProvider.SET_METHOD_WORKAROUND,
> > true)
> >
> >
> > Best Regards,
> >
> >
> > Colin Williams
> > _______________________________________________
> > jersey-dev mailing list
> > jersey-dev@xxxxxxxxxxx
> > To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jersey-dev__;!!GqivPVa7Brio!P3AaszBZQyjVXPwEj_K3UXwNElyb7EoDqyjUBcaJItsDxS84zXaysPe__QGL3RYB$
> _______________________________________________
> jersey-dev mailing list
> jersey-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jersey-dev