How to implement client authentication?

[mzdk100]

The server needs to authenticate each request in order to know which user the request belongs to.
What I can think of is passing the user ID in each request method, but if there are too many request methods, a lot of such logic code needs to be written.
Is there a way to pass headers when the client connects?

[tikue]

Thanks for your question! I think generally authentication would be done at the transport later, before initializing the rpc client / service. Maybe the TLS example would help clarify things?

[mzdk100]

This example implements encrypted transmission, which is good, but it doesn't solve my problem. I hope that after the client connects, it can send some headers, and the server can get them through context.get_header("user_id") similar things, rather than passing user_ID every time in the method call (here user_id may need to be passed to the database for user profile queries later).

First, TCP is a long connection, so the user information should be valid throughout the current connection, there's no need to repeat send user_id for every method call, sending it once is enough;

Second, I want to eliminate the user_id: String parameter on the server side and the get_user_id() call in the client side, so that the service.call1(get_user_id(), ...) and service.call2(get_user_id(), ...) can be simplified and the get_user_id() call is not needed every time.

[tikue]

Could you possibly implement a handshake using a separate rpc service, and after the handshake, move the transport into another channel for the post-handshake rpc service?

[mzdk100]

I've tried, but I'm not very proficient in the tarpc framework, so I haven't implemented it yet.

[mzdk100]

I hope there can be more examples.

[clarkmcc]

This doesn't really matter to me because I'm using my own already-authenticated custom transport, but grpc-go provides context metadata and I can see how that would be useful in this library, especially given the fact that there's already a propagated context type.

[mzdk100]

This doesn't really matter to me because I'm using my own already-authenticated custom transport, but grpc-go provides context metadata and I can see how that would be useful in this library, especially given the fact that there's already a propagated context type.

For the context here, I think the most important thing should be the purpose of metadata transmission.