Ok, thanks for the clarification.
On Thu, 4 May 2023 at 08:29, Eric Anderson wrote:
> On Thu, May 4, 2023 at 7:29 AM Brad Post wrote:
>
>> Okay thanks, but then what is the recommended way of "defending" bad
>> requests.
>>
>
> Ignore this case and just validate requests like you normally
On Thu, May 4, 2023 at 7:29 AM Brad Post 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
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, 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
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
