Thanks Carl. I'm trying to use async calls without streaming.
On Monday, November 12, 2018 at 5:37:56 PM UTC+5:30, qplc wrote:
>
> Hi,
>
> I've implemented below service definition in my grpc server/client
> application.
>
> service TestService {
> rpc testRPCCall(stream Test) returns (stream
Your connection issue is due to proxy configuration on your machine. As you
can see gRPC is connecting to a proxy for localhost.
http_connect_handshaker.cc:300] Connecting to server localhost:50051 via
HTTP proxy ipv4:10.19.8.225:912
Try setting http_proxy= or try no_proxy=localhost.
On
This is the discussion thread for gRFC L43:
https://github.com/grpc/proposal/pull/116.
This gRFC proposes a new standard for sharing/handling message type
information for gRPC methods in the Node libraries.
--
You received this message because you are subscribed to the Google Groups
"grpc.io"
I don’t know the C++ gRPC api but would assume there is a method to configure
and control the SSL transport layer. Almost have to be otherwise you need to
duplicate the entire SSL api.
> On Nov 19, 2018, at 2:55 PM, solomon lifshits wrote:
>
> You got totally right what I was asking about,
You got totally right what I was asking about, the question is whether
there is any plan to make that support on grpc/c++ legit, rather than test
only.
On Monday, November 19, 2018 at 3:00:07 PM UTC-5, eagle wrote:
>
> Robert Engels > writes:
>
> > I’m not sure I follow. The client knows the
Here is how to do it with Go
https://stackoverflow.com/questions/44295820/disable-common-name-validation-go-http-client
> On Nov 19, 2018, at 2:00 PM, Russ Allbery wrote:
>
> Robert Engels writes:
>
>> I’m not sure I follow. The client knows the host it is expecting to
>> contact and
Robert Engels writes:
> I’m not sure I follow. The client knows the host it is expecting to
> contact and verified that the certificate sent matches that host. As I
> said in a later email there is almost certainly a way to bypass the
> check but not sure you can change the setting while going
I’m not sure I follow. The client knows the host it is expecting to contact and
verified that the certificate sent matches that host. As I said in a later
email there is almost certainly a way to bypass the check but not sure you can
change the setting while going through gRPC layer.
> On Nov
Robert Engels writes:
> The certificate has the domain in it. So, think of the reverse. Someone
> highjacks the domain and uses a bogus certificate (valid but not for the
> real company) If the two weren’t linked there would be no way to stop
> this (as the certificate is still valid)
> By
Also, when this happens in a browser there will be security warnings, but the
user can still bypass it. With automated systems this is harder to do, there
may be an option with the underlying SSL provider on the platform being used to
perform a similar bypass (since the browser can bypass it
The certificate has the domain in it. So, think of the reverse. Someone
highjacks the domain and uses a bogus certificate (valid but not for the real
company) If the two weren’t linked there would be no way to stop this (as the
certificate is still valid)
By linking the certificate and the
Thank you for reply. The only thing I am trying to "bypass" is the DNS
resolution, so could you please elaborate how DNS resolution contributes to
SSL security?
On Monday, November 19, 2018 at 2:06:31 PM UTC-5, Robert Engels wrote:
>
> I’m pretty sure what you are asking breaks the security of
I’m pretty sure what you are asking breaks the security of using SSL... the
certificates are issued to a domain for that reason, otherwise any valid
certificate would be acceptable to the caller.
> On Nov 19, 2018, at 12:33 PM, solomon lifshits wrote:
>
> Since the function
Since the function SetSslTargetNameOverride is marked as test only, I am
asking whether there is any "legal" alternative to connect to a server
with specific IP address, while using a host name for server name
indication? Any possibility for forced resolution of a hostname? If a tls
Yang Gao is right, those get intentionally dropped. You should not
workaround that and send them over a unsecured medium if you are not
absolutely sure this is no security risk: Like when this application never
gets in contact with the internet and only runs inside of a company network.
--
Thanks for update on this!
Can someone merge https://github.com/grpc-ecosystem/grpc-opentracing/pull/43 to
prevent confusion?
Thanks
Tom
On Mon, Nov 19, 2018 at 8:43 AM Benjamin Krämer
wrote:
> Hi Tom,
>
> https://github.com/grpc-ecosystem/grpc-opentracing is not maintained
> anymore. So
I can read from documentation:
"A client-streaming RPC is also similar to our simple example, except the
client sends a stream of requests to the server instead of a single
request. The server sends back a single response, typically but not
necessarily after it has received all the client’s
Hi Tom,
https://github.com/grpc-ecosystem/grpc-opentracing is not maintained
anymore. So please use https://opentracing.io/ as main source. This will
forward you to https://github.com/opentracing-contrib/ (that you already
found). There we maintain all of the OpenTracing related contributions,
18 matches
Mail list logo
