One thing to realize is that Protobuf is not always going to serialize the message the same way, so you'll need to use raw bytes to wrap the message anyways.
I'm surprised that the interceptor is a lot of boiler plate; what language are you using gRPC with? Lastly: gRPC is protobuf agnostic. You can use it without using proto at all, so you should always be able to get at the raw message bytes, and not just through the call credentials api. On Thu, Feb 8, 2018 at 10:19 PM Haiwei Zhou <[email protected]> wrote: > Thanks for replying. > > TLS had been adopted, otherwise call credentials cannot be used. > > A RPC service is designed to handle core logic. A Web service provides UI > to proxy user request to the RPC service. Then a request signature should > be introduced to verify the real authorization. > > Using customized interceptor means a lot of boilerplate code, which I try > to avoid. The best way I guess is that call credentials API provides raw > request buffer. > > > On 9 February 2018 at 11:34, 'Carl Mastrangelo' via grpc.io < > [email protected]> wrote: > >> To do this, you'll need to wrap the serialized proto. Actually, you >> don't even need to put the signature in the headers. For example: >> >> >> message Wrapper { >> bytes signature = 1; >> bytes message = 2; >> } >> >> >> From the client: >> >> 1. Serialize your messsage >> 2. Put this in field 2 >> 3. Sign the message and put this in field 1. >> >> Send the wrapper as your message type. >> >> From the server: >> >> 1. Receive the wrapper proto >> 2. Verify the signature on the data >> 3. Deserialize the data. >> >> >> You can also do this from an interceptor, which would make the process >> transparent from the application point of view. >> >> That said, you're probably better off just using TLS with a client side >> certificate, which the server can verify and then you can trust all the >> data that comes over the wire. >> >> >> On Thursday, February 8, 2018 at 1:27:04 AM UTC-8, [email protected] >> wrote: >>> >>> Hi, >>> >>> I try to use call credentials to verify the request sanity: >>> >>> In the client, >>> serialize the request to string, >>> sign the string, >>> and send the signature as metadata. >>> >>> In the server, >>> serialize the request to string, >>> sign the string, >>> sign the request, >>> and compare the signature to the one in metadata. >>> >>> It works perfect until I met a message with a map. Protobuf >>> serialization doesn't guarantee the order of map items. >>> >>> How could I get original serialization string of the request in the >>> server side using python API? >>> >>> Thanks, >>> Haiwei >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "grpc.io" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/grpc-io/SPAv92gUypA/unsubscribe. >> To unsubscribe from this group and all its topics, 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/e1cfcfca-9da1-4439-b4e3-d9a37d533648%40googlegroups.com >> <https://groups.google.com/d/msgid/grpc-io/e1cfcfca-9da1-4439-b4e3-d9a37d533648%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/CAAcqB%2Bv40RPKB2Hn__W3KjO0ytsm4CRw60k_449syXVTvGgBjA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
