Changes in the App middlewares doesn't affect middlewares inside Group

[e-max]

Hi guys!

I've experienced problem similar to described here #445 (problem on middleware skipping)
But also I am having problem with Middleware.Replace and so on. I've checked the fix but not sure that I understood it.

I noticed that my problems were related to Resources so I continued looking into source code and I found this function in https://github.com/gobuffalo/buffalo/blob/master/router.go#L185

func (a *App) Group(groupPath string) *App {
	g := New(a.Options)
	g.Prefix = path.Join(a.Prefix, groupPath)
	g.Name = g.Prefix

	g.router = a.router
	g.Middleware = a.Middleware.clone()
	g.ErrorHandlers = a.ErrorHandlers
	g.root = a
	if a.root != nil {
		g.root = a.root
	}
	a.children = append(a.children, g)
	return g
}

Wouldn't the line :

g.Middleware = a.Middleware.clone()

cause problems?
Doesn't it mean that all changes you apply to Middleware stack after your create Group (or Resource) won't affect this Resource middlewares?

[markbates]

The routing system is top down. So you should layout your routes and middleware accordingly. It’s designed that way so it reads as it behaves without strange side affects that might be surprising to people. I would find it very strange if things I applied after other things were all of a sudden before those things. buffalo t middleware buffalo t routes Those two commands show you you’re entire middleware and routing stacks

…

-- Mark Bates HeOn Aug 16, 2018, 10:05 AM -0400, e-max <[email protected]>, wrote:

Hi guys! I've experienced problem similar to described here #445 (problem on middleware skipping) But also I am having problem with Middleware.Replace and so on. I've checked the fix but not sure that I understood it. I noticed that my problems were related to Resources so I continued looking into source code and I found this function in https://github.com/gobuffalo/buffalo/blob/master/router.go#L185 func (a *App) Group(groupPath string) *App { g := New(a.Options) g.Prefix = path.Join(a.Prefix, groupPath) g.Name = g.Prefix g.router = a.router g.Middleware = a.Middleware.clone() g.ErrorHandlers = a.ErrorHandlers g.root = a if a.root != nil { g.root = a.root } a.children = append(a.children, g) return g } Wouldn't the line : g.Middleware = a.Middleware.clone() cause problems? Doesn't it mean that all changes you apply to Middleware stack after your create Group (or Resource) won't affect this Resource middlewares? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[e-max]

Hi Mark.
I guess I just thought about Middlewares as a totally independent stack of function which applies before (and after) every request. I didn't think about it as a part of hierarchical routing architecture. So when I was deciding how to deal with authentication in tests I decided that the best way is to app.Replace my Authorize middleware with an empty function. Obviously, it didn't work.

It's much clearer now, thanks for the answer.

[markbates]

I've added a PR that adds more comments to make it clearer: #1233

I did, at one point go down that path you're describing, but it turned out to be very complex as there is no clear definition of "when" to "finalize" the stack. doing on each request was really slow, but caching it meant, again, choosing a "finalize" point that probably wouldn't have made people too happy. Then when you realize that most of how the middleware works is a bunch of magic to get around Go not letting do things like using functions as map keys, etc... you find out it's a big juggle. :)

Doesn't mean if someone came along with an awesome solution we wouldn't be open to it, it just means that I wasn't able to find a good solution, and this seemed like the most sane "compromise" for making it easier to understand.