gRPC message validation question

[Brad Post]

Is there a built in validator to ensure that the message passed to a method is the correct one?

For example:

message GetAddressInfoRequest {

    string street = 1;

    string zip = 2;

};

rpc get_address_info(GetAddressInfoRequest) returns (GetAddressResult);

I would like the function (get_address_info) to throw an exception/error if the signature for the incoming message doesn't match the GetAddressInfoRequest signature.

Thanks.

Brad

[Eric Anderson]

No, there is no validation. The type arguments are implicit given the method, and there's no communication that would tell you that there is a mis-match. The only time you'd need such a thing is if you change the request/response message in the proto, so "don't do that." Instead, create a new function with the new signature that you want.

--
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 grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/92d1edcd-6ef4-4a98-a415-34d2256a72d1n%40googlegroups.com.

[Brad Post]

Okay thanks, but then what is the recommended way of "defending" bad requests.  

If I have a message that is:

message ValidateStreetRequest {

     string street = 1;

};

I can pass this to my function above because the street field is aligned with the GetAddressInfoRequest but there is no validation from the rpc call that it was called with the correct message.

As both messages have required fields I could check the size of the message against what's expected, but that doesn't help me when fields are optional.

Any suggestions?

Thanks.

Brad

[Eric Anderson]

On Thu, May 4, 2023 at 7:29 AM Brad Post <br...@passportfintech.com> wrote:

Okay thanks, but then what is the recommended way of "defending" bad requests.

Ignore this case and just validate requests like you normally would if it were the proper type.

You can use this as a reminder that if you persist client-created messages in a DB, you very well may want to strip unknown fields. But that is not specific to this case.

I can pass this to my function above because the street field is aligned with the GetAddressInfoRequest but there is no validation from the rpc call that it was called with the correct message.

"can". It should be exceedingly rare to happen by accident. The most likely case of it happening by accident (other than you changed your schema in an incompatible way) is if you and another team at your company chose the same service name and method name in the same package. And if you did that, because of naming conventions, you probably would have both chosen the same request/response names!

If you are concerned about attacks, then you couldn't trust the type sent by the client anyway.

As both messages have required fields I could check the size of the message against what's expected, but that doesn't help me when fields are optional.

Then you will already have validation that the two fields are present, and maybe things like zip code follows an expected format. Do those validations. "Wrong message" is really just "invalid message of the right type."

Note that this line of thinking applies equally to messages that are fields in other messages. Protobuf does not include the types of child messages. Neither does JSON.

[Brad Post]

Ok, thanks for the clarification.