APP-2985: Protos for endpoint to register fusionauth applications #460
Conversation
app/v1/end_user.pb.go
Outdated
| type RegisterApplicationRequest struct { | ||
| state protoimpl.MessageState | ||
| sizeCache protoimpl.SizeCache | ||
| unknownFields protoimpl.UnknownFields | ||
|
|
||
| ApplicationName string `protobuf:"bytes,1,opt,name=application_name,json=applicationName,proto3" json:"application_name,omitempty"` | ||
| ApplicationId string `protobuf:"bytes,2,opt,name=application_id,json=applicationId,proto3" json:"application_id,omitempty"` | ||
| OrgId string `protobuf:"bytes,3,opt,name=org_id,json=orgId,proto3" json:"org_id,omitempty"` | ||
| OriginUris []string `protobuf:"bytes,4,rep,name=origin_uris,json=originUris,proto3" json:"origin_uris,omitempty"` | ||
| RedirectUris []string `protobuf:"bytes,5,rep,name=redirect_uris,json=redirectUris,proto3" json:"redirect_uris,omitempty"` | ||
| } |
There was a problem hiding this comment.
@ohEmily could you weigh in on these params and if they make sense?
There was a problem hiding this comment.
Curious about omitempty. I thought we shouldn't do omitempty for OriginUris, RedirectUris, OrgId and ApplicationName, unless we intend to do app-side validation for those. Wouldn't omitempty mean that the fields are optional? Out of these, I believe ApplicationId is the only optional one that should have omitempty.
There was a problem hiding this comment.
think i commented on the wrong thing here but these were the autogenerated protos so dont think i have control over the omitempty
proto/viam/app/v1/end_user.proto
Outdated
| // Allows users to register third party applications using Viam linked to the indicated organization | ||
| rpc RegisterApplication(RegisterApplicationRequest) returns (RegisterApplicationResponse); |
There was a problem hiding this comment.
[minor] can we make it RegisterAuthApplication?
proto/viam/app/v1/end_user.proto
Outdated
|
|
||
| message RegisterApplicationRequest { | ||
| string application_name = 1; | ||
| string application_id = 2; |
There was a problem hiding this comment.
Continuing on my comment that I made earlier, I initially thought application_id should be marked optional. Although thinking about it more, maybe we should just omit it entirely and force using an auto-generated application ID. The reason is that this is required to be globally unique, and then we don't have to handle customers using an application ID like "app" and wrapping the FusionAuth response to give a detailed exception.
There was a problem hiding this comment.
from the ticket description:
Our gRPC endpoint should have application name and redirect URIs should be required parameters. (i.e. don’t use FusionAuth’s built in feature of generating a random client ID)
was thinking this meant we wanted them to pass an application id from the parenthesis, may have misunderstood. can remove if thats not the case!
assume you mean |
jr22
added
protos-compiled
bug
|
(ty katherine, trying to help me figure out this protos compiled thing) |
APP-2985
Created protos to register fusion auth apps. Not sure if
end_useris the right place for this? was thinking maybe but still getting acquainted with this stuff so open to feedback if it should be moved elsewhere.