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
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:
(defnhandler [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-authorizationnil) ; 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 backend
Possible fix
(defnwrap-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)))))))
The text was updated successfully, but these errors were encountered:
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
andthrow-unauthorized
, those exceptions would arrive viaraise
callback. One such instance could be a OAuth2 authorization backend calling the token endpoint. A simplified example:Possible fix
The text was updated successfully, but these errors were encountered: