-
Notifications
You must be signed in to change notification settings - Fork 10.3k
AuthorizeHelper will no-op if endpoint routing is used #10471
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
Conversation
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.
src/SignalR/common/Http.Connections/src/ConnectionEndpointRouteBuilderExtensions.cs
Show resolved
Hide resolved
src/SignalR/common/Http.Connections/src/ConnectionEndpointRouteBuilderExtensions.cs
Outdated
Show resolved
Hide resolved
app.UseRouter(routes.Build()); | ||
app.UseRouting(); | ||
app.UseAuthorization(); | ||
app.UseEndpoints(endpoints => |
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.
@davidfowl
Have any thoughts on this? Converting app.UseSignalR(r => r.Map...())
to use Endpoints internally. This lets us get rid of our custom auth stuff in HttpConnectionDispatcher
.
And side-effect, I believe will allow apps that port to 3.0 but don't change to endpoints to use the service automagically without UseAzureSignalR
. (Once I figure out the HubMetadata
issue)
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 to me seems super spicy. Does it make sense to deprecate this API now that it's literally equivalent to something else? It's goodness if we can converge all of the code that we show in samples/docs.
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 would be ok deprecating the old stuff
@anurse @davidfowl ?
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'm OK marking UseSignalR
as obsolete if that's what we're talking about. We should have done that already anyway, since we want people to use UseEndpoints
.
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 would be obsoleting:
UseConnections
ConnectionsRouteBuilder
HubRouteBuilder
UseSignalR
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.
Sounds good.
Ping reviewers, I basically rewrote the change so we no longer do Auth inside The one remaining thing is that |
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.
Auth changes kinda makes sense, but would be great if somebody more familiar with SignalR's routing signed off on this.
Can you explain why this is the case? |
747869b
to
c85d231
Compare
I've just made a commit with a fix, I didn't do it initially because it's a bit ugly, but I don't have a better solution right now. |
} | ||
|
||
[Fact] | ||
public async Task AuthenticatedUserWithoutPermissionCausesForbidden() |
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.
Do we still have end-to-end coverage for cases like 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.
We do have some end-to-end tests for auth, for example: https://github.com/aspnet/AspNetCore/pull/10471/files#diff-c65c848cc599ae1724a72656ff60bedaR453
But we don't need to verify it as much because we now rely on the underlying auth system instead of implementing our own version.
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.
Do we still manually verify authorization for hub method invocations to account for method-level auth attributes over a WebSocket for example? Where is that?
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.
Yes we still do. This PR doesn't touch any of that.
Test located 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.
Yeah, I can't speak to the specific tests that are being removed, but I'd strongly encourage testing a variety of auth scenarios and interactions as a user would write them.
/azp run all |
No pipelines are associated with this pull request. |
@aspnet/build What's going on? |
@BrennanConroy looks like AzDO missed your comment or hit a temporary glitch. Later, the Hello bot ignored your triage request. That bot seems to get confused when the URL doesn't exactly match a known format (see aspnet/AspNetCore-Internal#2425). In this case, |
|
||
namespace Microsoft.AspNetCore.Http.Connections.Internal | ||
{ | ||
internal static class AuthorizeHelper |
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.
It makes me super happy to see this go away. We basically have 3 version of this code rn, and this cuts it down to two.
src/SignalR/common/Http.Connections/test/MapConnectionHandlerTests.cs
Outdated
Show resolved
Hide resolved
@@ -25,6 +28,11 @@ public HubRouteBuilder(ConnectionsRouteBuilder routes) | |||
_routes = routes; | |||
} | |||
|
|||
internal HubRouteBuilder(IEndpointRouteBuilder endpoints) |
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.
Worth a comment explaining why and when this can be null?
[Authorize] | ||
class AuthHub : Hub | ||
{ | ||
} |
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.
So is the expectation that method-level auth doesn't play with endpoints or with the authZ middleware?
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 left a few teeny comments, but this looks like what I expected to see, and this seems like valuable simplification.
@dougbu I doubt it: #10425 (comment) |
@BrennanConroy that was a whole week ago ❕ More seriously, we don't know why the bot sometimes ignores triage requests. |
endpoint => | ||
{ | ||
Assert.Equal("/path/negotiate", endpoint.DisplayName); | ||
Assert.NotNull(endpoint.Metadata.GetMetadata<IEnableCorsAttribute>()); |
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.
Look @anurse, I did a thing!
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.
But do you have a test that verifies CORS headers are actually set? :)
/azp run AspNetCore-ci |
Azure Pipelines failed to run 1 pipeline(s). |
/azp run AspNetCore-ci |
Azure Pipelines could not run because the pipeline triggers exclude this branch/path. |
/azp run AspNetCore-ci |
Azure Pipelines successfully started running 1 pipeline(s). |
Fixes #9216
If I understand correctly, Auth will run on the Endpoint metadata (which we set the authorize metadata correctly) so internally SignalR doesn't need to run Auth again in the Endpoint code path.