-
Notifications
You must be signed in to change notification settings - Fork 6
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
Replace authn.Request for *http.Request #9
Conversation
Any chance this can get merged? 😊 |
eb79a33
to
87caeaf
Compare
Replaces authn.Request with *http.Request for better interop. Signed-off-by: Edward McFarlane <[email protected]>
87caeaf
to
b3a3e19
Compare
@terinjokes @seandlg thanks the interest. I've had to rewrite the history to sign commits. The PR has been updated to reflect the new proposal. |
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 use case for Procedure
and Protocol
in this package? I've not needed to reach for them and they aren't used in the examples either.
@terinjokes the use case would be for authorization on specific methods. The example in #12 showcases using an allowlist base on which method is invoked. Protocol has been brought up before as some users wish to disable one or the other entirely. |
Signed-off-by: Edward McFarlane <[email protected]>
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 looks very lean. I have implemented authentication with this PR in my repo and the testing is a breeze, given that I can simply craft http.Request
and test my AuthFunc
.
d86599a
to
1144c96
Compare
Signed-off-by: Edward McFarlane <[email protected]>
1144c96
to
478629f
Compare
Also works well in my project and allowed me to delete a bunch of code from the tests. Is it possible to do a release from 7013291 to allow the protocol functions to be moved to the runtime without blocking the improvements here? |
I think we'll want to finish connectrpc/connect-go#756 and get that merged before merging this so that when this lands, the accessors we are removing already have suitable replacements. Otherwise, I think this PR is probably ready to merge. |
Signed-off-by: Edward McFarlane <[email protected]>
acd94c8
to
a8cdbbd
Compare
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.
Why not keep the implementations and tests you had over in the connect-go PR? They seemed strictly more correct.
authn.go
Outdated
if len(procedure) < 4 { // two slashes + service + method | ||
return request.URL.Path | ||
} |
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.
Same remark as in connect-go PR. This would incorrectly allow "//foo".
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.
Added a testcase.
authn.go
Outdated
// "/service/method". If the request path does not contain a procedure name, the | ||
// entire path is returned. | ||
func InferProcedure(request *http.Request) string { | ||
path := strings.TrimSuffix(request.URL.Path, "/") |
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.
Why do we do this? Do connect RPC servers actually accept an invalid trailing slash like this? Pretty sure gRPC servers are usually strict and do not allow 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.
Removed allowing trailing suffix.
authn.go
Outdated
default: | ||
return connect.ProtocolConnect |
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 no value in returning "unknown" (or empty string, etc) when the request doesn't look like any of these? Since this is middleware, it seems highly likely it could be used with a mux that has both connect and non-connect routes, so I think we do need better classification here.
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.
Now return "", false.
Bumps google.golang.org/protobuf from 1.32.0 to 1.33.0. Bumps buf from 1.27.0 to 1.33.0. Migrate buf configuration files to v2. Done by `buf config migrate`. Regenerates the proto files used for testing. Upgrades min supported go version to v1.20.x. Signed-off-by: dependabot[bot] <[email protected]> Signed-off-by: Edward McFarlane <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Edward McFarlane <[email protected]> Signed-off-by: Edward McFarlane <[email protected]>
See connectrpc/connect-query-es#386 Signed-off-by: Dan Rice <[email protected]> Signed-off-by: Edward McFarlane <[email protected]>
Signed-off-by: Dan Rice <[email protected]> Signed-off-by: Edward McFarlane <[email protected]>
Signed-off-by: Josh Humphries <[email protected]> Signed-off-by: Edward McFarlane <[email protected]>
Upgrade go to 1.23 with min 1.21. Update deps. Fix lint issues. Signed-off-by: Edward McFarlane <[email protected]>
Signed-off-by: Edward McFarlane <[email protected]>
dfff6c0
to
a20d53d
Compare
Signed-off-by: Edward McFarlane <[email protected]>
@jhump updated to move the connect-go implementation here. |
To improve testability of
authn
middleware and remove API surface inauthn
this PR proposes dropping theauthn.Request
in favour of*http.Request
. This is a breaking change to the API. We remove all references toauthn.Request
objects which is replaced by accessing the*http.Request
directly.Fixes #8