Best method to authorize a TCP microservice client?

[leaden creek]

I assume the only way is through a message pattern like "authenticate" where you validate the payload and maybe assign a key to the underlying socket. Otherwise validate each message with a guard using switchToRpc().getData() and checking and validating the desired authentication details e.g. apiKey

or should I just suck it up and use NATs

[sudden hollow]

Well, in theory, your TCP server should take a username/password to connect to in the first place, so any connection to it should already be authenticated, at least in theory/best practices. As for authenticating each message, I'm not 100% sure, I'll need to play around with the idea a bit

[leaden creek]

do you mean basic auth?

[sudden hollow]

Yeah, you should be able to specify that to connect to the TCP server in the first place a basic surviving scheme is needed. I'm pretty sure that options exist

[leaden creek]

there is no option to specify basic auth when registering the tcp microservice afaik

just to clarify you are saying that this should work:

const app = await NestFactory.createMicroservice<MicroserviceOptions>(
    AppModule,
    {
      transport: Transport.TCP,
      options: {
         username: '',
         password: ''
      }
    },
  );
  await app.listen();

{
  host: 'username:password@domain'
}

[sudden hollow]

I think so. But I'll need to play around with it. Maybe another blog article on that coming soon 😉

[leaden creek]

I'm

quite sure those fields don't exist nor are read in the TCPServer clas

ok first I have to playaround with how guards itnteract

with a tcp message

[sudden hollow]

Right, but I think they should. Like I said, I'll look into it

[leaden creek]

also the TcpSocket class exposes a function called netSocketwhich returns the socket (which is already public readonly) it was instantiated with. This leads me to believe that the ServerTCP class which has a field named server and is of type NetSocket (alias for net.Server) which instantiates the TcpSocket was meant to pass that in as well. Otherwise it's a pointless getter function unless the public readonly socket field was meant to be private.

I also noticed that despite getOptionsProp() allowing a third optional parameter as the default value, all the servers prefer getOptionsProp(options, key) || defaultValue) instead

aside from that, from my fiddling I've determined that in order for there to be basic auth support for the tcp transport it needs some sort of metadata field on the TcpSocket so that when the server receives a socket, it tells that socket to send over the "headers" which can then be processed by a guard.

[sudden hollow]

Ah, hmm, looks like I was generally wrong with basic Node TCP servers. I'll try to play around with this and find a solution for you 🙂

Plus it'll make for another good blog post