Authentication for accessing Google PubSub (and other third-party APIs) about grpc HOT 5 CLOSED

Did you ever manage to get your GRPC client for Google Cloud PubSub working @clearjs?

I had similar problems with Google Cloud Bigtable. With the emulator everything worked as it should but when targeting googleapis.com I got a 404. After debugging with Wireshark and finding the differences between an official bigtable client for nodejs and mine using grpc-elixir I found the problem.

It turns out the problem is the Content-Type set by default in grpc-elixir to application/grpc+proto, googleapis expect that to be application/grpc. You can change the content-type easily as grpc-elixir already supports it, just set content_type: "application/grpc" using the opts part of the service calls defined in the stub.

Thanks to @tony612 for creating grpc-elixir and protobuf-elixir!

from grpc.

I pushed a sample (not yet working) implementation here: https://github.com/clearjs/pubsub-grpc-auth-elixir. I tried an approach similar to https://medium.com/@KevinHoffman/mutual-tls-over-grpc-with-elixir-a071d514deb3.

Here are my new settings: https://github.com/clearjs/elixir-auth/blob/master/priv/client.exs.

I added CA certificates from https://github.com/certifi/erlang-certifi for channel authentication.

I also included a certificate and a private key files, although they don't seem to have any effect:

• generated GOOGLE_APPLICATION_CREDENTIALS JSON file with google console, saved value from its private_key field to a client-key.pem file, replacing '/n' with actual newline

• followed the url from client_x509_cert_url field, and saved a certificate corresponding to the private_key_id field (60b7a01a580e8c38554e0c9ed1494791a6396798 in this case) to client-cert.pem file, also replacing '/n'

I still use goth for generating tokens for per-call authentication and put them to authorization header after "Bearer " prefix.

But when I execute the client code above, I'm getting the following error when server_name_indication is not set in ssl parameters:

[info] ['TLS', 32, 'client', 58, 32, 73, 110, 32, 115, 116, 97, 116, 101, 32, 'certify', 32, 'at ssl_handshake.erl:1335 generated CLIENT ALERT: Fatal - Handshake Failure - {bad_cert,hostname_check_failed}', 10]
{:error, "Error when opening connection: :timeout"}

If it is set to any value, only the last (timeout) error appears.

If we disable verification: verify: :verify_none, grpc returns the following error:

{:error, %GRPC.RPCError{message: "status got is 404 instead of 200", status: 13}}

and swallows the following:

<ins>That’s an error.</ins>\n <p>The requested URL <code>/google.pubsub.v1.Publisher/ListTopics</code> was not found on this server.

which is a bit strange, as I think that gRPC calls always go to the same URL, pubsub.googleapis.com, and only :path HTTP2 header should change. And the URL above looks correct. Probably it is not being found because of incorrect authentication.

from grpc.

Based on the 404 error, it seems the TLS works? I think your guess("incorrect authentication") is right. I didn't use Google PubSub, but I guess you should use gRPC metadata(like custom headers in HTTP/1) to pass the token. The way you tried to pass token is wrong

list_topics(req, token: token)

You can find examples in https://github.com/tony612/grpc-elixir/blob/master/interop/lib/interop/client.ex#L93

from grpc.

@ssboisen thanks for sharing this! This task has been on hold until yesterday, but now I plan to finish it. I added content_type as you suggested, and it now works!

project_id="..." # your project_id from Google PubSub
token="..." # token string from Goth
{:ok, channel} = GRPC.Stub.connect("pubsub.googleapis.com:443", [cred: GRPC.Credential.new(ssl: [])])
req = Google.Pubsub.V1.ListTopicsRequest.new(project: "projects/#{project_id}", page_size: 5)
{_, _reply} = channel |> Google.Pubsub.V1.Publisher.Stub.list_topics(req, token: token, content_type: "application/grpc")

I used my fork of grpc-elixir which takes the token param and uses it to set the authentication header. However, as I mentioned in #72 (comment), there's a better way to do authentication. I'll implement it and make a pull request soon.

@tony612 you're right that

The way you tried to pass token is wrong

This way works only with my fork (https://github.com/clearjs/grpc-elixir), and it's better to implement it differently: pass a function that returns tokens when creating %GRPC.Channel{} and let it use that. There's no need for using custom headers, however. Just adding authentication: Bearer <token> header is enough.

from grpc.

@ssboisen Yes. I noticed similar problems in other projects. I'll consider change default content-type to application/grpc.

from grpc.