Fix to parse protoreflect.Message instead of parsing the value returned by v.String() #5436
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does:
For messages for proto's custom Service options, instead of using the string obtained with v.String(), we have modified it so that the value is obtained by reflection using protoreflect.
I checked not to show the diff in the
service.pb.auth.go
Why we need it:
The output of v.String() for the proto Message type changes depending on the byte data of the compiled binary.
More detail:
The protoc-gen-auth plugin generates the restriction logic for the api request based on the role.
We can define the option in the rpc definition like below.
Then, generate the logic in the
service.pb.auth.go
.pipecd/pkg/app/server/service/webservice/service.pb.auth.go
Lines 95 to 132 in b9882f7
It reads the proto file and generates Go code in the following steps:
generateMethods
refEspecially about 1,
generateMethods
do in the following steps:pipecd/tool/codegen/protoc-gen-auth/main.go
Line 127 in 17a5007
At timing 2, v.String() may be "resource:PIPED action:CREATE" (two spaces between elements) or "resource:PIPED action:CREATE (one space between elements)" .
This flaky behavior is the protobuf specification.
When you execute String() on a protobuf Message, MessageStringOf is called.
This is one of the example↓
ref: https://github.com/protocolbuffers/protobuf-go/blob/ec47fd138f9221b19a2afd6570b3c39ede9df3dc/types/dynamicpb/dynamic.go#L96-L99
MessageStringOf internally uses prototext.MarshalOptions.Format.
ref: https://github.com/protocolbuffers/protobuf-go/blob/ec47fd138f9221b19a2afd6570b3c39ede9df3dc/internal/impl/api_export.go#L173-L177
According to the official doc the result of using prototext package is , flaky on purpose.
To avoid relying on something that is not clearly defined, it intentionally makes the value indefinite for undefined behavior.
According to these issues, the format for displaying protobuf as string is not clearly defined. So they introduce randomization of the result.
About the randomization:
Internally, a hash is created based on the executable binary, and the remainder of the hash divided by 2 is used to determine whether to insert additional spaces, and this value changes every time the program is compiled.
https://github.com/protocolbuffers/protobuf-go/blob/ec47fd138f9221b19a2afd6570b3c39ede9df3dc/internal/encoding/text/encode.go#L216-L234
Especially, it is archieved using
detrand.Bool
.https://github.com/protocolbuffers/protobuf-go/blob/ec47fd138f9221b19a2afd6570b3c39ede9df3dc/internal/detrand/rand.go#L24-L69
Which issue(s) this PR fixes:
Fixes #5430
Does this PR introduce a user-facing change?: