Open FreGalle opened 4 years ago
Would it be better to expect a user of the driver to provide ALL grpc dial options he wants to use, including WithInsecure
and/or WithTransportCredentials
?
Not sure why I missed this at the time of reporting this, but the workaround I mentioned (specifying the command-line flags) will still result in the grpcclient.SecureDialOption
grpc.WithTransportCredentials
option to be applied AFTER any similar option passed in to the driver configuration by the user, effectively limiting the applicability of the workaround to the most basic TLS configurations.
Overview of the Issue
When using the Go vitess driver I wanted to configure TLS to connect to vtgate. Turns out that providing a
WithTransportCredentials
grpc.DialOption
as part of thevitessdriver.Configuration.GRPCDialOptions
results in the following error when trying to execute a query.grpc: transport credentials are set for an insecure connection (grpc.WithTransportCredentials() and grpc.WithInsecure() are both called)
Looking into it some more the culprit seems to be the usage of the
SecureDialOption
function ingrpcvtgateconn.DialWithOpts
which includes aWithInsecure
DialOption unless some flags are provided on the command line.I want to inject my own tls configuration because the one that is constructed based on the grpcvtgateconn flags is too basic for my needs. The only way this currently works is to both specify the flags (so no
WithInsecure
option is added) and also pass on my ownWithTransportCredentials
option through the driver configuration.Reproduction Steps
Add your own
grpc.WithTransportCredentials
to thevitessdriver.Configuration.GGRPDialOption
slice without providing the vtgate_grpc_cert,... flags.