For the sake of convenience across multiple (sometimes layered) authorization scenarios (meaning, some controllers require standard HTTP auth, but some controllers are explicitly for use by an app that has to present certain identity headers), I use middleware for auth rather than the onAuth HTTP hook. I’m running a patched version of onRoute to disable the middleware timeouts, since a timeout in the middleware would enable a client to hit an endpoint controller they may not be authorized to hit. While I agree middleware should be fast, there may be database connectivity issues, etc. At the very least, I would expect the application would throw if the middleware timed out, not fall through to the controller.
Also, if middleware throws an error, the client is sent a 404, rather than a 500. I would expect that the proper behavior is to handle errors inheriting from HttpError the same as if they were thrown from a controller, and throw anything else as a 500.
For the sake of convenience across multiple (sometimes layered) authorization scenarios (meaning, some controllers require standard HTTP auth, but some controllers are explicitly for use by an app that has to present certain identity headers), I use middleware for auth rather than the
onAuthHTTP hook. I’m running a patched version ofonRouteto disable the middleware timeouts, since a timeout in the middleware would enable a client to hit an endpoint controller they may not be authorized to hit. While I agree middleware should be fast, there may be database connectivity issues, etc. At the very least, I would expect the application would throw if the middleware timed out, not fall through to the controller.Also, if middleware throws an error, the client is sent a 404, rather than a 500. I would expect that the proper behavior is to handle errors inheriting from
HttpErrorthe same as if they were thrown from a controller, and throw anything else as a 500.