Service Gateway & authentication

I’m learning the great Sevice Gateway feature. I wonder how to deal with authentication invoking a service/operation through the gateway.

Looking at the wiki

public object Any(GetCustomerOrders request)
    return new GetCustomerOrders {
        Customer = Gateway.Send(new GetCustomer { Id = request.Id }),
        Orders = Gateway.Send(new QueryOrders { CustomerId = request.Id })

GetCustomerOrders will be protected as usual, but let assume “QueryOrders” requires Authentication as well.
I assume the QueryOrders operation could be invoked also directly so it will require authentication as well.
How should I instruct the Gateway to forward the authentication (for ex. a jwt token) validated for “GetCustomerOrders” to the n operation invoked through the gateway?

Am I on the right track or I’m missing somenthing?

The internal Gateway Services have access to the same IRequest and User Session that was validated by the external Service. When implementing a custom ServiceGateway you would capture the IRequest and forward the BearerToken from the IRequest to the Service Client used, e.g:

public class CustomServiceGatewayFactory : ServiceGatewayFactoryBase
    private IRequest req;
    public override IServiceGateway GetServiceGateway(IRequest request)
        this.req = request;
        return base.GetServiceGateway(request);

    public override IServiceGateway GetGateway(Type requestType)
        var isLocal = HostContext.Metadata.RequestTypes.Contains(requestType);
        var gateway = isLocal
            ? (IServiceGateway)base.localGateway
            : new JsonServiceClient(alternativeBaseUrl) {
                BearerToken = req.GetBearerToken()
        return gateway;

To save an overload in future, the ServiceGatewayFactoryBase captures the IRequest in base.Request from this commit.

That’s clear how to forward the original jwt token.

But where do I get the

I should get that from the ServiceRegistry/Discovery according to the requestType.
Consul plugin has its own implementation, so the Redis I assume.

With no Service Discovery registered, the “alternativeBaseUrl” should be handled manually (extrnal dto -> baseUrl)?

That’s whatever remote ServiceStack instance that you want to forward the request to, each ServiceDiscovery solution is going to have its own implementation.

Ok that’s clear: if no discovery will be used, the gateway has to know the final(s) endpoint by itself.
IOW the gateway acts as “sugar programming” avoiding to create a JsonServiceClient anytime directly within the code.

About the

who should take care to dispose the instance created within the CustomServiceGatewayFactory?
a JsonServiceClient should be explicitly disposed after using it or the GC can take care on its own?

Service Clients don’t need to be explicitly disposed, each request creates and disposes a new .NET HttpWebRequest which get connection pooled behind-the-scenes, so they’re just normal object instances which are taken care of by the GC.

If the service clients all have an empty implementation of Dispose why implement IDisposable in the first place? I see that it’s IMessageProducer that originally inherits it. I’m sure there is a good reason, I just don’t know what it is. :slight_smile:

It was just leaving room for implementations that do need to be disposed.

I see. Thanks for that.