-
-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(microservice): add TLS over TCP support #7516
Conversation
add tcp tls client options add tcp tls server options add tcp over tls support
add tcp tls client options add tcp tls server options add tcp over tls support
… into feat/microservice-tcp-tls
fix client-tcp not beeing able to handle empty options
fix isCustomClientOptions type-guard not beeing able to handle undefined
For docs, should I update the docs in I think we could either add another section in: Or make an own page for |
Pull Request Test Coverage Report for Build a18b5f60-086f-4c47-a111-2d294565e81c
💛 - Coveralls |
add TcpTlsOptions to MicroserviceOptions type
Correct
Let's add a new section in the TCP chapter |
fix client not connecting when using tls
Docs have been updated as well, the PR is linked above |
I can add a sample later that I used for testing, should I include a self-signed certificate in the sample? |
return new ClientTCP(options as TcpClientOptions['options']); | ||
const uncheckedOptions = options as | ||
| TcpClientOptions['options'] | ||
| TcpTlsClientOptions['options'] | ||
| undefined; | ||
if (uncheckedOptions && uncheckedOptions.useTls === true) { | ||
return new ClientTCP(options as TcpTlsClientOptions['options']); | ||
} else { | ||
return new ClientTCP( | ||
options as TcpClientOptions['options'] | undefined, | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this condition seems to be used only for type-checking purposes, can we just force cast options
to the appropriate type and remove this if
?
if (options === undefined) { | ||
this.options = {}; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the reason for this change?
|
||
// describe('tls', () => { | ||
// it('should upgrade to TLS', () => { | ||
// const jsonSocket = new ClientTCP({ useTls: true }).createSocket(); | ||
// expect(jsonSocket.socket).instanceOf(TLSSocket); | ||
// }); | ||
// it('should not upgrade to TLS, if not requested', () => { | ||
// const jsonSocket = new ClientTCP({ useTls: false }).createSocket(); | ||
// expect(jsonSocket.socket).instanceOf(NetSocket); | ||
// }); | ||
// }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this intentionally commented out?
I left a few comments. Can we also add an integration test? |
Hi, ty for the the feedback I'll try work on this this weekend. |
| KafkaOptions['options']).serializer) || | ||
( | ||
options as | ||
| RedisOptions['options'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you think about extracting these types into a Union type declared, something like :
| RedisOptions['options'] | |
const type Options = NatsOptions['options'] | |
| MqttOptions['options'] | |
| TcpClientOptions['options'] | |
| TcpTlsClientOptions['options'] | |
| RmqOptions['options'] | |
| KafkaOptions['options']; |
Currently I dont have that much time to work on this @AnisJS09 Do you want to continue? |
Okay, I managed to get some time to continue working on this. Looking into integration testing right now. It seems like there are no e2e tests for TCP implemented atm. |
Ahh alright. I completely missed that. Will work on this later then and finish this feature request. |
add integration tests
Okay, I added the e2e tests. |
if (this.useTls) { | ||
this.netSocket.connect(this.port, this.host); | ||
source$ = this.connect$( | ||
this.socket.netSocket, | ||
ERROR_EVENT, | ||
TLS_CONNECT_EVENT, | ||
).pipe( | ||
tap(() => { | ||
this.isConnected = true; | ||
this.socket.on(MESSAGE_EVENT, (buffer: WritePacket & PacketId) => | ||
this.handleResponse(buffer), | ||
); | ||
}), | ||
share(), | ||
); | ||
} else { | ||
source$ = this.connect$(this.socket.netSocket).pipe( | ||
tap(() => { | ||
this.isConnected = true; | ||
this.socket.on(MESSAGE_EVENT, (buffer: WritePacket & PacketId) => | ||
this.handleResponse(buffer), | ||
); | ||
}), | ||
share(), | ||
); | ||
this.socket.connect(this.port, this.host); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the only difference here is whether to use netSocket
or socket
(depending on whether TLS is on) we should probably refactor this logic to avoid repetitiveness.
@Flusinerd @kamilmysliwiec is this actively being worked on? I would be happy to pick it up |
Hi. I don't think so. Feel free to continue |
Moving onto this PR #10628 |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Adds an additional property
useTls?: boolean
to the options for client and server. If useTls is set, it intersects the Nodes tls server / client options with the nest server/client options.If useTls is set to true, it uses node's
tls
module instead ofnet
to allow TCP over TLS supportWhat is the current behavior?
Issue Number: #6745
What is the new behavior?
If
useTls === true
then it will usetls
instead ofnet
to create the server / client and intersect the appropriate options with the nest optionsDoes this PR introduce a breaking change?
Other information