I needed to add an authorisation header to all outgoing requests from the client, and I added a ClientRequestFilter as instructed in this answer.
Now I want to change the properties of the filter I created. I tried to re-register a new copy of the filter but that didn't work. I tried to look through the available methods of the Client object but didn't find anything like de-register or remove.
Sample Code:
Client client = ClientBuilder.newClient().register(new ClientObjectMapperProvider());
AuthTokenFilter authTokenFilter = new AuthTokenFilter(authTokenService, authConfig);
client.register(authTokenFilter);
//make some requests
//In another method in another class
AuthTokenFilter newFilter = new AuthTokenFilter(authTokenService, newConfig);
client.register(newFilter);
//make more requests
When I send requests after registering the new filter, I want the auth header to be different according to the new config, but that's not happening.
On further investigation it seems that the client object will not register an object if another of the same type is already registered. Still haven't found a way to de-register though.
Creating Client instances is quite heavyweight so you don't want to do that very often, hence it makes sense that you are caching and reusing the client instance.
If you simply wish to have a separate authentication filter per targeted endpoint then registration doesn't have to be done on the client instance. Before you can actually talk to anything you need to create a WebTarget (which represents a concrete endpoint to which you are to communicate) Once you've created your WebTarget you can register your filter with that.
Configuring webtarget's can also be fairly heavy weight (see here)
but it does mean that you can spawn (and cache) different authentication filters per targeted host.
If you are wanting to dynamically reconfigure your client/webtarget based on some edited configuration (e.g. properties file/configuration REST endpoint) then you
can simply have a cache of WebTarget/Client instances which you regenerate from scratch when the configuration changes. (You need to remember to call client.close() before discarding any old client instance)
Related
I'm using Vert.x for my web service, where a part of it required authorization. I've set an AuthenticationHandler (using the OAuth2 implementation from vertx-auth-oath2) to listen on the protected paths (lets say "/*") and it is correct called, sends a redirect to the authentication provider, which redirects back and then correctly to the real handler. This works fine.
But the next time we call the protected endpoint - it does the whole thing again. I see that in the abstract AuthenticationHandlerImpl class it checks if the context already has a user() and if so - will not run the actual auth handler, which is the behavior I need - but it obviously doesn't happen because every call is a new request with a new RoutingContext.
What is the "correct" way to retain the User object across requests, so that the auth handler will be happy?
I'm guessing it has something to do with session storage but I've never used that - up until now I was using a custom "API key" style solution, and I'm trying to do this "The Right Way(tm)" in this new project.
I'm using the latest Vert.x 4.3.5.
You will need CookieHandler and SessionHandler to store and handle session with user. This will work out of the box with provided vertx-auth-oath2.
Here is a simple example to get you started:
https://github.com/vert-x3/vertx-examples/blob/master/web-examples/src/main/java/io/vertx/example/web/auth/Server.java
I have an AuthenticationServerInterceptor for grpc-java, that authenticates any request. However, the request processing itself is split into multiple threads.
For the sake of simplicity lets assume, that there are 3 parts (that are potentially executed by different threads):
Establishing the request and doing the authentication
[1..* times] Processing the parts of the request
Closing the request
What should I pass to the other places in order to allow me to restore the authenticated context in the later cases? (All three parts belong to a single request and they share a grpc-context)
The Authentication instance
The SecurityContext instance
If I pass along the Authentication instance, then I ensure that for each part of the request the original authentication is restored. However, any additional information that might be stored in the (custom) security context will be lost.
If I pass along the SecurityContext instance, then I ensure that for each part of the request the additional information and an authentication are passed along, but the developer must be careful with modifying that context.
Unfortunately I couldn't find any information about which to pass along in the docs.
I cannot just decide on either of those, because the authentication process is part of a library and it doesn't know anything about whether there might be additional details in the context and what the developer might do when processing the request parts.
Here is my current implementation, that is tested to be working+thread safe:
https://github.com/yidongnan/grpc-spring-boot-starter/blob/2ee90f16ee4295370ee47c40829805ff1a9f4f51/grpc-server-spring-boot-autoconfigure/src/main/java/net/devh/boot/grpc/server/security/interceptors/DefaultAuthenticatingServerInterceptor.java#L59
TLDR: Is spring-security's SecurityContext more thread-scoped or more request-scoped?
The problem is that the default option in Spring Security is thread Local, meaning that if your request create new threads, these new ones will be created with an empty Security context. You can set it to mode Inheritable Thread Local with the following code:
#Bean
public MethodInvokingFactoryBean methodInvokingFactoryBean() {
MethodInvokingFactoryBean methodInvokingFactoryBean = new MethodInvokingFactoryBean();
methodInvokingFactoryBean.setTargetClass(SecurityContextHolder.class);
methodInvokingFactoryBean.setTargetMethod("setStrategyName");
methodInvokingFactoryBean.setArguments(new String[]{SecurityContextHolder.MODE_INHERITABLETHREADLOCAL});
return methodInvokingFactoryBean;
}
I have two instances of clients with different configs that I am creating (timeout, threadpool, etc...), and would like to leverage Dropwizard's metric on both of the clients.
final JerseyClientBuilder jerseyClientBuilder = new JerseyClientBuilder(environment)
.using(configuration.getJerseyClientConfiguration());
final Client config1Client = jerseyClientBuilder.build("config1Client");
environment.jersey().register(config1Client);
final Client config2Client = jerseyClientBuilder.build("config2Client");
environment.jersey().register(config2Client);
However, I am getting
org.glassfish.jersey.internal.Errors: The following warnings have been detected:
HINT: Cannot create new registration for component type class org.glassfish.jersey.client.JerseyClient:
Existing previous registration found for the type.
And only one client's metric shows up.
How do I track both clients' metrics or is it not common to have 2 clients in a single dropwizard app?
Never mind, turned out I was an idiot (for trying to save some resource on the ClientBuilder).
2 Things that I did wrong with my original code:
1. You don't need to register Jersey clients, just the resource is enough... somehow I missed the resource part in my code and just straight up trying to register the client
2. You need to explicitly build each JerseyClientBuilder and then build your individually configured clients, then dropwizard will fetch by each JerseyClientBuilder's metrics
In the end, I just had to change my code to the following:
final Client config1Client = new JerseyClientBuilder(environment)
.using(configuration.getJerseyClientConfiguration()).build("config1Client");
final Client config2Client = new JerseyClientBuilder(environment)
.using(configuration.getJerseyClientConfiguration()).build("config2Client");
Doh.
environment.jersey().register() has a javadoc listing of Adds the given object as a Jersey singleton component meaning that the objects registered become part of the jersey dependency injection framework. Specifically this method is used to add resource classes to the jersey context, but any object with an annotation or type that Jersey looks for can be added this way. Additionally, since they are singletons you can only have one of them per any concrete type (which is why you are getting a "previous registration" error from Jersey).
I imagine that you want to have two Jersey clients to connect to two different external services via REST/HTTP. Since your service needs to talk to these others to do its work, you'll want to have the clients accessible wherever the "work" or business logic is being performed.
For example, this guide creates a resource class that requires a client to an external http service to do currency conversions. I'm not saying this is a great example (just a top google result for dropwizard external client example). In fact, I think this not a good to structure your application. I'd create several internal objects that hide from the resource class how the currency information is fetched, like a business object (BO) or data access object (DAO), etc.
For your case, you might want something like this (think of these as constructor calls). JC = jersey client, R = resource object, BO = business logic object
JC1()
JC2()
B1(JC1)
B2(JC2)
R1(B1)
R2(B2)
R3(B1, B2)
environment.jersey().register(R1)
environment.jersey().register(R2)
environment.jersey().register(R3)
The official Dropwizard docs are somewhat helpful. They at least explain how to create a jersey client; they don't explain how to structure your application.
If you're using the Jersey client builder from dropwizard, each of the clients that you create should be automatically registered to record metrics. Make sure you're using the client builder from the dropwizard-client artifact and package io.dropwizard.client. (Looks like you are because you have the using(config) method.)
I am writing a web server in java using vertx.
I use the server as a proxy to other services, and I'm the the testing stage. I want to know that I have created the request correctly with custom tokens and headers.
But, I cant manage to find a way to receive the properties upon creation.
HttpClientRequest clientRequest = vertx.createHttpClient().request(HttpMethod.GET,80,"host","/path?query=value");
When I try to read the host clientRequest.getHost() I receive a null, but in debug, reading its values, I can see a property named delegate which contains all of its data.
How can I access those values from clientRequest?
What you see in debug is:
((HttpClientRequestImpl) req).host
While getHost() method actually returns you hostHeader
For testing purposes I suggest to cast your HttpClientRequest to HttpClientRequestImpl, as it will expose more data.
If everything else fails, you can also fall back to reflection, of course.
There is a webapp, where every request consumes various external resources. The webapp tracks those consumed resources with request scooped bean. Then HandlerInterceptor's afterCompletion method calls TaskExecutor to store this information in DB. All is fine and dandy, but there goes the requirement to add bandwith consumption as another resource. Counting outgoing response size is a typical task for servlet filter (along with response wrapper and custom stream implementation). So this is done and is also working.
The problem is that I'd like to aggregate two things together. Obviously, I can't pass "bytes sent" to Spring HandlerInterceptor, because filter's doFilter() hasn't completed yet and the amount of bytes sent isn't known when the interceptor runs. So filter must be the place to aggregate all the resource usage and start async task to store it in DB. The problem is: how can I pass data from HandlerInterceptor to Filter. I've tried simple request.setAttribute() but surprisingly it didn't worked.
As a side note: I'm aware of request scooped bean lifecycle and at the handler I'm creating a simple POJO populated with data from scooped bean.
The problem turned out to be quite trival. The app was doing a lot of forward/dispatches as a part of somehwat normal request handling. It turned out that the my filter was called (so far, so good) then another filter down the chain was doing forward/dispatch which then did actual request processing. Default filter setup catches only plain requests and you need additional configuration (web.xml) to also filter forwards/dispatches. I just did that and that solved the problem.