Skip to content

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

Merged
merged 12 commits into from
Jun 3, 2019

Conversation

BrennanConroy
Copy link
Member

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.

@BrennanConroy BrennanConroy added the area-signalr Includes: SignalR clients and servers label May 22, 2019
Copy link
Contributor

@pranavkm pranavkm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@analogrelay analogrelay added this to the 3.0.0-preview6 milestone May 23, 2019
app.UseRouter(routes.Build());
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
Copy link
Member Author

@BrennanConroy BrennanConroy May 24, 2019

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)

Copy link
Member

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.

Copy link
Member Author

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 ?

Copy link
Contributor

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.

Copy link
Member Author

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good.

@BrennanConroy
Copy link
Member Author

Ping reviewers, I basically rewrote the change so we no longer do Auth inside HttpConnectionDispatcher and rely on Auth through Endpoint routing.

The one remaining thing is that app.UseSignalR(routes => routes.MapHub<MyHub>("/path")); doesn't set the HubMetadata on the Endpoint produced.

Copy link
Contributor

@pranavkm pranavkm left a 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.

@halter73
Copy link
Member

The one remaining thing is that app.UseSignalR(routes => routes.MapHub("/path")); doesn't set the HubMetadata on the Endpoint produced.

Can you explain why this is the case?

@BrennanConroy
Copy link
Member Author

Can you explain why this is the case?

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()
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member

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.

@BrennanConroy
Copy link
Member Author

/azp run all

@azure-pipelines
Copy link

No pipelines are associated with this pull request.

@BrennanConroy
Copy link
Member Author

@aspnet/build What's going on?

@BrennanConroy
Copy link
Member Author

@dougbu
Copy link
Contributor

dougbu commented May 30, 2019

@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, &view=logs probably busted it.


namespace Microsoft.AspNetCore.Http.Connections.Internal
{
internal static class AuthorizeHelper
Copy link
Member

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.

@@ -25,6 +28,11 @@ public HubRouteBuilder(ConnectionsRouteBuilder routes)
_routes = routes;
}

internal HubRouteBuilder(IEndpointRouteBuilder endpoints)
Copy link
Member

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
{
}
Copy link
Member

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?

Copy link
Member

@rynowak rynowak left a 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.

@BrennanConroy
Copy link
Member Author

@dougbu I doubt it: #10425 (comment)

@dougbu
Copy link
Contributor

dougbu commented May 31, 2019

@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>());
Copy link
Member Author

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!

Copy link
Contributor

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? :)

@BrennanConroy BrennanConroy added the breaking-change This issue / pr will introduce a breaking change, when resolved / merged. label May 31, 2019
@BrennanConroy
Copy link
Member Author

/azp run AspNetCore-ci

@azure-pipelines
Copy link

Azure Pipelines failed to run 1 pipeline(s).

@BrennanConroy
Copy link
Member Author

/azp run AspNetCore-ci

@azure-pipelines
Copy link

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

@BrennanConroy
Copy link
Member Author

/azp run AspNetCore-ci

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@BrennanConroy BrennanConroy merged commit f0df10f into master Jun 3, 2019
@ghost ghost deleted the brecon/noopAuth branch June 3, 2019 05:35
@BrennanConroy
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-signalr Includes: SignalR clients and servers breaking-change This issue / pr will introduce a breaking change, when resolved / merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[SignalR]: AuthorizeHelper should no-op if endpoint routing has already executed auth
8 participants