Middlewares: How to apply only to existing routes

[DRSDavidSoft]

Hey @mathieucarbou,

As I’m wrapping up my authentication handler (referenced in this issue), I have a small but important detail that I’m unsure how to handle.

I’d like to attach an AuthenticationMiddleware to the entire server, but it should only apply to existing routes.

One approach I considered is attaching it to individual routes rather than the whole server. However, this isn’t ideal, especially when dealing with numerous routes.

Another option I thought of is detecting whether next() leads to the catch-all handler (i.e., the "not found" route) and skipping authentication in such cases -- but while this sounds simple, it doesn’t seem to be a straightforward task. 😅

To achieve this, I’m considering enumerating all attached handlers.
I’d love to hear your thoughts on the best way to approach this. Thanks!

---

EDIT I would like to be notified of this:

ESPAsyncWebServer/src/WebServer.cpp

Line 143 in 673431e

// ESP_LOGD("AsyncWebServer", "No handler found for %s, using _catchAllHandler pointer: %p", request->url().c_str(), _catchAllHandler);

[mathieucarbou]

I’d like to attach an AuthenticationMiddleware to the entire server, but it should only apply to existing routes.

In that case, just attach it to the routes: a middleware can be attached globally to the server or to routes.

However, this isn’t ideal, especially when dealing with numerous routes.

No, it depends how your app is built. In your case, you would need to have a class that is wrapping the calls and applies the auth middleware depending on the params passed. Something like:

static AsyncCallbackWebHandler& secure(const char *uri, WebRequestMethodComposite method, ArRequestHandlerFunction onRequest) {
  return server.on(uri, method, onRequest).addMiddleware(&digestAuth);
}

then, just call your secure() method

[DRSDavidSoft]

@mathieucarbou Please consider this, as the _runChain() is being executed after _attachHandler, it should definitely be possible to know which handler was assigned to this particular request, and interact with it.

Here's what I'm referencing...

ESPAsyncWebServer/src/WebRequest.cpp

Lines 191 to 199 in 673431e

	_server->_runChain(this, [this]() {
	return _handler ? _handler->_runChain(
	this,
	[this]() {
	_handler->handleRequest(this);
	}
	)
	: send(501);
	});

And the _attachHandler() is called just a bit above that:

ESPAsyncWebServer/src/WebRequest.cpp

Line 661 in 673431e

_server->_attachHandler(this);

Is it a bad idea to make a public function to get a reference to the handler and interact with it? I can call methods of that handler, or maybe even replace the handler that is going to be called, from a middleware itself! Would this be dangerous or bad practice? I ask this, because otherwise it would be an awesome functionality to have!

[mathieucarbou]

@DRSDavidSoft : this is just a pointer in a list so not a big deal.

For your request about knowing which handler will be executed, this is not in line with the middleware concept as seen on webservers.

Middleware typically should not car about the handler pinter that will be executed because they are either attached globally or to specific handler so their code is already specific in this case to the handler attached.

I really think that all your request comes from a wrong design that should be improved in your app.

That's not the sever goal to cope with application specific needs.

The webserver api should be simple and efficient and be kept as-is. If you have specific need due to the way your app is developed, this is up to you to work around that.

[mathieucarbou]

@DRSDavidSoft I was just thinking also that with request attributes, you have a way to pass some data from middleware to handler and handler to middleware back (after handler execution). So in the case of a global handler on server, you cannot know before calling next() which handler will be executed, but you can know it after next() providing your handler added some data in the request attributes.

[DRSDavidSoft]

Great info, and I agree 👍🏻 I'm thinking about the request class, AsyncWebServerRequest. At any time when interacting with the request object, the user application might get some information about it, considering the request cycle flow (starting from middleware and ending in handler).

It will always be up to the user to what to do with it, I would just appreciate if the _handler that is currently attached would be exposed to the request object, so I can either know what it is currently set to, or interact with the handler itself.

Note that currently, the handler of the ongoing request can be changed at any time that we have access to request:

ESPAsyncWebServer/src/ESPAsyncWebServer.h

Lines 315 to 317 in 673431e

	void setHandler(AsyncWebHandler *handler) {
	_handler = handler;
	}

In fact, that's how _attachHandler does it:

ESPAsyncWebServer/src/WebServer.cpp

Lines 136 to 145 in 673431e

	void AsyncWebServer::_attachHandler(AsyncWebServerRequest *request) {
	for (auto &h : _handlers) {
	if (h->filter(request) && h->canHandle(request)) {
	request->setHandler(h.get());
	return;
	}
	}
	// ESP_LOGD("AsyncWebServer", "No handler found for %s, using _catchAllHandler pointer: %p", request->url().c_str(), _catchAllHandler);
	request->setHandler(_catchAllHandler);
	}

Now, since setHandler() exists and is marked as public, then any middleware has the option to change the handler that is going to be called for the ongoing request. ✅

Next, it would be nice to have a getHandler() method, that returns the reference for the already attached Handler for the current request.

I'm trying to access that to see if the current request's handler type is the catch all one.

Since the request class has the following classes as a friend, then I might be able to access it:

ESPAsyncWebServer/src/ESPAsyncWebServer.h

Lines 185 to 186 in 673431e

	friend class AsyncWebServer;
	friend class AsyncCallbackWebHandler;

Right now, only handlers are friends with the request class.

[DRSDavidSoft]

Personally I wouldn't really mind if my user application doesn't fully confront to the conventions of middlewares, it might be bad practice in other libs, but since the Handler is known at the time middlewares are being executed, it's a nice method to check if the URL exists, i.e. if something is going to "handle" it at the end of the middleware chain. 👍🏻

[DRSDavidSoft]

@mathieucarbou Is it possible to ask the following as a feature request:

The AsyncWebServerRequest class should introduce a new getHandler() method in addition to the existing setHandler() method.

[mathieucarbou]

I don't think this is acceptable.

Now, since setHandler() exists and is marked as public, then any middleware has the option to change the handler that is going to be called for the ongoing request. ✅

This method is for internal purpose only and should NEVER be used by a user and is not / should not be documented.
My assumption is that it was made public either my mistake or to facilitate some spi implementation.
The handler is selected based on some internal rules. User code should not change that from a middleware. There are some use case also (long lived requests) where this could even cause a crash.

@me-no-dev can confirm or a explain more why this method is public, but what I am 100% sure is that such method won't exist anymore in v4.

There shouldn't be any mutable link between the request and the future handler that will process a request. Both have different life cycle and applying some logic based on what will process the request (handler ) on a middleware is just like saying that a middleware gets specialized in taking decision about how to process the request. There are many other API that exist already to probably help your use case to so that, like canHandle which can be overridden or setFiter.

Instead of trying to adapt something to fit your code which is not publicaly available, let's try to see how to make your use case work, which is to only run middlewares on routes that have been setup.

Thanks:-)

[DRSDavidSoft]

This method is for internal purpose only and should NEVER be used by a user and is not / should not be documented.

Does this mean that now that I mentioned it, it's going to be removed from public access 🥲

There shouldn't be any mutable link between the request and the future handler that will process a request.

I see. Well I understand your point, and I agree that a well-designed architecture wouldn't allow for this.

what I am 100% sure is that such method won't exist anymore in v4.

Alright, so I'm not going to rely on this, if this will certainly be removed in v4.... 😬

... just like saying that a middleware gets specialized in taking decision about how to process the request

well, that wasn't entirely my point, I meant that whenever the request object happens to be accessible to the user, the setHandler() method also is. It isn't just the middlewares, I can also call setHandler() from a handler's handle itself. (not that i am going to do it, just saying that it is accessible)

Instead of trying to adapt something to fit your code which is not publicaly available, let's try to see how to make your use case work, which is to only run middlewares on routes that have been setup.

Most important thing that must have been said. Ouch! Sorry for going it this way.

My MO for implementing this was to study exactly how the code works, so I could introduce the minimal set of required changes so I can inject my functionality :D

Not that it's the best way, but I wanted to avoid additional trouble, and implement it myself. Not the best idea, last time I asked for a small change to the _attachHandler() function, you created an entire middleware support feature.

Thanks for creating such amazing code! 👍🏻

[mathieucarbou]

@DRSDavidSoft : I have raised a PR here: #50 to:

• Allow to skip global server middleware on any handler
• Allow to access the catch-all handler to add middlewares on it

I added an example showing how to use that: https://github.com/ESP32Async/ESPAsyncWebServer/blob/feat/skip-server-middleware/examples/SkipServerMiddleware/SkipServerMiddleware.ino

  // we apply auth middleware to the server globally
  server.addMiddleware(&basicAuth);

  // protected endpoint: requires basic authentication
  // curl -v -u admin:admin  http://192.168.4.1/
  server.on("/", HTTP_GET, [](AsyncWebServerRequest *request) {
    request->send(200, "text/plain", "Hello, world!");
  });

  // we skip all global middleware from the catchall handler
  server.catchAllHandler().skipServerMiddlewares();
  // we apply a specific middleware to the catchall handler only to log requests without a handler defined
  server.catchAllHandler().addMiddleware(&logging);

  // standard 404 handler: will display the request in the console i na curl-like style
  // curl -v -H "Foo: Bar"  http://192.168.4.1/foo
  server.onNotFound([](AsyncWebServerRequest *request) {
    request->send(404, "text/plain", "Not found");
  });

• you can skip the global middleware for any handler you want, including the catch-all/
• you can add middleware to any handler, including catch-all.

[DRSDavidSoft]

Wow, such a complete approach! 👍🏻

If this gets merged, it would certainly address all of the requirements for my use case, thanks!

I'm a bit hesitant regarding the added flash/memory consumption vs. what I originally proposed, but functionality-wise, I'm 100% aboard implementing this! 👍🏻

A quite nice side effect is that using this PR, any hadler can skip the middlewares (if required) rather than just the catch all handler.

@mathieucarbou thanks for the quick implementation 🎉 and so sorry for the trouble

The middlewares feature is so new in the library that i'm sure other people haven't yet had the time to try complex designs. implementing this PR will contribute towards completing the new, shiny middleware support in ESPAsyncWebServer.

Does the code in the PR require further testing/reviews? If not, I'd appreciate it getting merged! 😄

[DRSDavidSoft]

BTW your original idea of using a wrapper to add the middleware to the routes is awesome, but for my usecase, this is better 👍🏻

[mathieucarbou]

Yes, and more generally, we missed a way to skip global handlers and access the catch all hander.
Fyi @me-no-dev PR can be merged when you reviewed:-)