You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 ofonRoute
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.The text was updated successfully, but these errors were encountered: