Skip to content

[7.x] Allow disabling of global middleware #32404

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

Closed
wants to merge 2 commits into from
Closed

[7.x] Allow disabling of global middleware #32404

wants to merge 2 commits into from

Conversation

nmokkenstorm
Copy link
Contributor

@nmokkenstorm nmokkenstorm commented Apr 16, 2020

This PR aims to fix issue #32384, and is supplementary to PR #32347 by @dsazup , after discussion with @driesvints.

At time of writing global middleware doesn't support access to routes, because the route matching process is done after the global middleware stack has run. As a result, accessing the current route on Illuminate\Foundation\Http\Kernel works for terminable (global) middleware, but not for regular middleware.

I've moved the global middleware stack check to its own method, and manually match there now, but obviously there's a performance consideration there. The obvious solution is marking the findRoute method of Illuminate\Routing\Router as public and caching the actual lookup, but that'd be a breaking change in the contract. I'm open for thoughts on this.

@nmokkenstorm
Copy link
Contributor Author

@GrahamCampbell should be the correct branch now, I keep doing this wrong every time 😅

@nmokkenstorm nmokkenstorm marked this pull request as draft April 16, 2020 14:31
@taylorotwell
Copy link
Member

I don't think matching the request twice per app lifecycle is going to be a feasible solution.

@nmokkenstorm
Copy link
Contributor Author

I don't think matching the request twice per app lifecycle is going to be a feasible solution.

Agreed, hence the proposed caching option. If you're able to match a route for a given RouteCollection once, I don't see that change between calls. Do you have thoughts on that?

Alternatively the matching part could be moved up a bit in the cycle, but that's a bigger architectural change. I know that that is generally frowned upon as it might have a lot more side effects, but I'm willing to look into it if you feel the caching thing won't work out to your liking.

@taylorotwell
Copy link
Member

taylorotwell commented Apr 16, 2020

Personally my hunch at the current time would be that withoutMiddleware simply does not work with global middleware and we move on. If you want it to work with a global middleware, make that global middleware a route level middleware.

There is no other solution at the moment that is not very dangerous imo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants