With Ring 3-arity contract, exceptions thrown in the same thread bubble back to the middleware. However, if any non-blocking IO was to happen between wrap-authorization and throw-unauthorized, those exceptions would arrive via raise callback. One such instance could be a OAuth2 authorization backend calling the token endpoint. A simplified example:
(defn handler [request respond raise]
(future ; simulates non-blocking IO switching threads
(try
(throw-unauthorized) ; simplified example
(catch Throwable t (raise t))))) ; raise any handler exceptions per Ring spec
(-> handler
(wrap-authorization nil) ; backend doesn't get called anyway
(apply {:request-method :get} println println nil)) ; run it
; => #ExceptionInfo
; expected: wrap-authorization to catch the raised exception
; and handle it with the backendPossible fix
(defn wrap-authorization
(fn
; [...]
([request respond raise]
(try (handler request respond
(fn [e] (try (respond (authorization-error request e backend))
(catch Throwable t (raise t))))
(catch Exception e
(respond (authorization-error request e backend)))))))
With Ring 3-arity contract, exceptions thrown in the same thread bubble back to the middleware. However, if any non-blocking IO was to happen between
wrap-authorizationandthrow-unauthorized, those exceptions would arrive viaraisecallback. One such instance could be a OAuth2 authorization backend calling the token endpoint. A simplified example:Possible fix