Hi,
It definitely makes sense to avoid duplicating code everywhere.
You should look(for the server side) at implementing a
grpc::AuthMetadataProcessor.
This allows to access the `auth_metadata`, which can be used to pass
whatever you want between your clients and the server, via the headers.
In it, you also have access to the `:path` if you want to auth or not based
on the route.
For java client you can add the headers with CallCredentials.
And using c++ that would be a `grpc::MetadataCredentialsPlugin`.
The doc is indeed a bit sparse on this.
You can look at test/cpp/end2end/end2end_test.cc for inspiration, and some
other tests.
Good luck
On Monday, November 12, 2018 at 4:30:35 PM UTC+1, Stephan Menzel wrote:
>
> Hello gRPC community,
>
> I am in the process of a major overhaul to a C++ project using gRPC
> extensively. Much of the work concerns going from sync to async services.
> Another important part is new authentication and tokens.
>
> Up until now, all my messages, by contract, contained a field acting as a
> auth token for the user. Let's call it token:
>
>
>> message MyRequest {
>> pdm.PbAuthToken token = 1; // always given in
>> ... actual parameters
>> }
>
>
> There are template functions that add this token to all calls and others
> to read it back out, in order to verify authentication. Now I'm in the
> process of migrating to a different kind of token and verification and I
> came across a base class called CallCredentials, which appears to serve
> that very purpose but wrapped up in gRPC. Keen to explore this I came
> across this https://grpc.io/docs/guides/auth.html but that isn't very
> verbose on how this would be done.
>
> Basically, I want to attach my own token to every call (ideally, I would
> have some calls accepted without it as well) and not having to extract and
> verify it explicitly in every handler. And it must work in async server
> impls in order to be useful for me. Does anybody have bit of an example of
> this? Does it make sense to explore this or should I just stick to my
> existing mechanism?
>
> Best regards...
> Stephan
>
>
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/de88ccd6-ff14-4327-9ca0-167d3d8ae6bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
