-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: move permissions to shared, a new token proto #192
Conversation
proto/token.proto
Outdated
rpc GenerateTempAuthToken (_GenerateTempAuthTokenRequest) returns (stream _GenerateTempAuthTokenResponse) {} | ||
} | ||
|
||
message _GenerateTempAuthTokenRequest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This still needs to be finalized, alternative suggestions
- GenerateEphemeralAuthToken
- GenerateProvisionalAuthToken
- GenerateBriefAuthToken
- GeneratePerishableAuthToken
- GenerateDecayingAuthToken
- GenerateTransientAuthToken
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For better or worse, we have landed on GenerateAuthAcorn
.
proto/token.proto
Outdated
package token; | ||
|
||
service Token { | ||
rpc GenerateTempAuthToken (_GenerateTempAuthTokenRequest) returns (stream _GenerateTempAuthTokenResponse) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rpc GenerateTempAuthToken (_GenerateTempAuthTokenRequest) returns (stream _GenerateTempAuthTokenResponse) {} | |
rpc GetTemporaryAuthToken (_GetTemporaryAuthTokenRequest) returns (_GetTemporaryAuthTokenResponse) {} |
- I think you can just use "get" instead of "generate" to mean the same thing.
- We should prefer clear, full words like "temporary" over needless abbreviations like "temp."
- If you think you need a server-side streaming response, let's chat on slack. I'm guessing that was just a mistaken copypaste?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I think you can just use "get" instead of "generate" to mean the same thing.
- I like that
- We should prefer clear, full words like "temporary" over needless abbreviations like "temp."
- Yes, this name also happens to be temporary, this pr is in effort to get more of a discussion/decision on the API name
- If you think you need a server-side streaming response, let's chat on slack. I'm guessing that was just a mistaken copypaste?
- Yep, def a copypaste miss
I'll clean these up once name is settled
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we aligned in slack that we are not going to switch to Get
, we will keep Generate
for consistency with existing API. Jury might still be out on Temporary
vs other names
proto/auth.proto
Outdated
} | ||
|
||
Permissions permissions = 4; | ||
permissions.Permissions permissions = 4; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you try generating the protos for the web sdk and compiling the web sdk with them? we used some hacks there to get it to work with strictjs and I am worried that moving these messages to different packages is going to break it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cprice404 FYI ^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good callout, definitely worth testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got a successful build without package permissions
, did have to change imports, here's the javascript-web
changes
momentohq/client-sdk-javascript#729
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, this was a real pain. For Javascript-web
, I removed the package
declarations, but in doing so, rust builds will fail since tonic server seems to build protos into the out directory only if they're a package, couldn't find anything in the docs to help with this.
Noticing that the javascript-web
build script actually comments out package
(thank you @krispraws for the great comments), I thought I would keep the package declares and update permissions.Permissions
to Permissions
for javascript-web
only. It ain't pretty.
Got it working and auth test running in javascript-web
, javascript-nodejs
I was having much worse luck with, @grpc/grpc-js
is shared between the packages, so ChannelCredentials, Interceptor
had conflicts between the two different versions.
Here's what the JavaScript changes will look like momentohq/client-sdk-javascript#731
Alternatively to avoid all of this, we could maintain two copies of the permissions object in auth
and token
, but not a hug fan of this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the javascript-web build is already a rube goldberg machine. Personally I am okay with pushing more horror and complexity there rather than letting it bleed into other languages/SDKs. If @krispraws is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dumb question - Do we need to put each proto file/each grpc service in its own package? Can tokens.proto, permissions.proto and auth.proto all live in the same auth
package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @cprice404 - we can push the complexity into javascript-web builds.
option java_multiple_files = true; | ||
option java_package = "momento.shared.permissions"; | ||
|
||
package permissions; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we can avoid using a package here, that might be sufficient to keep the web sdk working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we need to test the web SDK but I don't know that I want to introduce a new inconsistency in our use (or lack thereof) of packages until we know there's a problem with the web SDK. I'd rather be consistent with our current conventions and see if we can solve it for Web SDK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. The hack will almost definitely break though, because even if we remove package permissions
temporarily, the types in it are still being referred to as permissions.*
in the other protos.
@@ -0,0 +1,96 @@ | |||
syntax = "proto3"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a diff in this file that we should be paying attention to, or is this just an unchanged migration to a separate file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No diff, unchanged migration to a separate file
proto/token.proto
Outdated
package token; | ||
|
||
service Token { | ||
rpc GenerateTempAuthToken (_GenerateTempAuthTokenRequest) returns (stream _GenerateTempAuthTokenResponse) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we aligned in slack that we are not going to switch to Get
, we will keep Generate
for consistency with existing API. Jury might still be out on Temporary
vs other names
} | ||
} | ||
|
||
message CachePermissions { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These message definitions are shared between regular v1 auth and acorn, however we don't actually want to support CacheItemSelector for v1 auth, right? Also, do we want to allow an acorn to be used for topics?
Perhaps it's clearer to have these restrictions in proto instead of mr2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, yes, the control-plane will reject generate v1 token request that include CacheItemSelector
, but if we do want to support CacheItemSelector
in v1 tokens later, i think it will be easier to make validation and sdk changes to allow rather then proto changes. Yes, we want to allow acorn's for us in topics, I think one of the key use cases for acorn's was browser chats.
i do think you're right that it's probably would be more clear, but I think the only groups that will have troubles are the brave souls using our proto's directly.
GenerateAuthToken
contains no new changes, only moving ofPermissions
messageGenerateTempAuthToken
request and response, is the same asGenerateAuthToken
however it doesn't include a expiration with option ofNever
and response will never include arefreshToken