On Thu, May 4, 2023 at 7:29 AM Brad Post <[email protected]> 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. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oNqGXjKHeBuUZfCiP_m9601T%3DsP5zp2RkXfHCiYMXTbDQ%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
