Grpc-java: Validation support

[thekalinga]

What version of gRPC are you using?

NA

What did you expect to see?

A provision to validate input data in a meaningful way, preferably using bean validation 2.0 (JSR 380)

My assumption is that currently I have to do adhoc validation for every single request & it defeats the whole purpose of having a framework like bean validation.

Is there any plan to integrate this with bean validation?

[ericgribkoff]

I'm not aware of any plans to support bean validation 2.0. That said, I'm also not familiar with the use cases for this type of validation or if that role might be filled by something else in the gRPC ecosystem.

cc @ejona86

[thekalinga]

I'm also not familiar with the use cases for this type of validation

1. Authorization
2. Does all the input data confirm to API spec. eg., username is not already registered/email format, e.t.c

[ejona86]

It's not clear how authorization would be handled in a bean validation world.

But for normal input data this seems like a protobuf concern. You probably want to open an issue in google/protobuf instead.

[thekalinga]

@ejona86 hibernate validator is a reference implementation of bean validation. It supports custom validators on methods arguments, return values & much more. In effect, if validation can be applied on the inputs, we can use custom logic to validate the current principal, his roles & verify whether he is allowed to access the given end point

[thekalinga]

I dont have much context of the protobuf spec (as I'm only app dev :)).

I see this in the fork of protobuf.

https://github.com/gogo/protobuf/issues/96

This looks very similar to the problem I raised here. Can you please go over it & confirm that this issue needs to go to protobuf/can be fixed within grpc itself (as grpc is the one that defined the structure for calls)?

[ejona86]

gRPC does not define the structure for calls. Most of that in protobuf (in the .proto files). gRPC just handles the method call part of it; the argument and return objects are protobuf while attaching them to a call is gRPC. So if there is a per-method validation, I guess that could impact gRPC. Most of the time people have been talking about message-level validation, which is in protobuf.

I do think it would be hard/impossible to support any return validation, because the async API uses generic callbacks and it doesn't seem callbacks would be easily handled by the validation framework.

[thekalinga]

@ejona86 Thanks for the explanation. You are right w.r.t method/endpoint level validation. Since streams involved, implementation of this might be tricky (as the endpoint/method level validation needs to be applied to each element within the http stream).

I will raise an issue against message validation for now (as this is more or less basic)

[SeriousMa]

@thekalinga use mine https://github.com/SeriousMa/grpc-protobuf-validation 😀

[thomas-silva]

@thekalinga have you raised a new issue for message validation yet? It would be great to annotate protobuf with validations that map to Java annotations supported by (JSR 380). Then higher level libs / frameworks like https://github.com/LogNet/grpc-spring-boot-starter can include features to run validations against the message bean.

[SeriousMa]

@thomas-silva
I raised this issue to the protobuf team
https://github.com/google/protobuf/issues/3256
It seems they dont want add this feature to the core lib
so i made my own...

[ST-DDT]

@SeriousMa @entur @envoyproxy I'll verify whether I need to change something in yidongnan/grpc-spring-boot-starter to support your validation interceptors and then open a PR which documents the required steps to automcatically configure the interceptor.

AFAICT this will look similar to this:

Integration with grpc-spring-boot-starter

To enable the validation in spring use the following bean defintion:

````java
@Configuration
public class ValidationConfiguration {

@GrpcGlobalServerInterceptor
public ValidationInterceptor grpcServerValidationInterceptor(ValidatorIndex index) {
    return new ValidationInterceptor(index);
}

}
````
[...]

In the meantime, could you explain which of those libraries is the precessor/successor of the other?
What are the differences between them? And are they available on Maven?

• https://github.com/entur/protobuf-validation
• https://github.com/SeriousMa/grpc-protobuf-validation
• https://github.com/envoyproxy/protoc-gen-validate/tree/master/java/pgv-java-grpc (Maven:heavy_check_mark:)

Or did I miss any?

If one of the libraries is the de-facto standard, then I would add direct support for it.

[mchopra8]

@thekalinga How did you validate the proto messages? I also need to implement the validation, so wanted to know your approach

[jvmlet]

LogNet's spring boot grpc starter natively supports Spring Validation integration via Java Bean Validation XML deployment descriptor. You are welcome to give it a try.
@thomas-silva