This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-15
Channels
- # adventofcode (13)
- # aleph (5)
- # announcements (8)
- # beginners (87)
- # calva (9)
- # cider (102)
- # cljs-dev (71)
- # cljsrn (2)
- # clojure (198)
- # clojure-dev (28)
- # clojure-europe (3)
- # clojure-italy (27)
- # clojure-nl (3)
- # clojure-spec (1)
- # clojure-uk (43)
- # clojurescript (121)
- # component (11)
- # cursive (20)
- # data-science (13)
- # datascript (2)
- # datomic (102)
- # dirac (4)
- # duct (5)
- # emacs (14)
- # figwheel-main (7)
- # fulcro (37)
- # hoplon (11)
- # jackdaw (3)
- # jobs (2)
- # leiningen (16)
- # nrepl (2)
- # off-topic (51)
- # pathom (34)
- # pedestal (12)
- # perun (10)
- # portkey (1)
- # re-frame (6)
- # reitit (1)
- # shadow-cljs (21)
- # spacemacs (8)
- # tools-deps (2)
- # vim (2)
500 errors/exceptions don't seem to add the cors header using ::http/allowed-origins
. All other requests do. Is there any way to add this without creating an error interceptor to repeat what the ::http/allowed-origins
param does. Or something else wrong here?
@caleb.macdonaldblack while Pedestal provides default error handling, I’d recommend implementing your own error handling interceptor which associates a more informative and, possibly, context-specific response. Adding such an error handling interceptor to your common interceptor collection will create a response which will be returns with the relevant CORS headers.
Here are some more details:
Default error handling is considered last resort and is interceptor chain provider specific. The servlet interceptor chain provider provides a catchall but it’s implemented within the internal response processing logic.
CORS is implemented as an interceptor and only supports the :enter
and :leave
keys. On :leave
it merges the relevant headers to the response :headers
map. There is no :error
support because, what should it do in the case of an error? This is an application-specific concern.
Explicitly handle your errors and you’ll get the result you are looking for.
BTW, when I talked about context-specific error handling, I was referring to the error-dispatch
helper provided by Pedestal (https://github.com/pedestal/pedestal/blob/master/interceptor/src/io/pedestal/interceptor/error.clj#L17).
Thank you for for your response. I left my question up to see if there were any other solutions. I did end up using error-dispatch though which is exactly what I needed
I just added a Unit Testing reference to the http://pedestal.io site (http://pedestal.io/reference/unit-testing). @ariel.silverman you may find it useful.
Thank you so much, I tried this approach but in my case since our service is wrapped inside a component I ended up creating a macro I am using as a fixture to exercise the response-for
function
(defmacro with-mock-ds-system
[[sym ds-factory] & body]
;; Create a system map with a mock datastore and a mock auth-checker, set ::http/join == false so
;; that the system doesn't block execution.
`(let [temp# ~ds-factory]
;; Store a reference to this system, perhaps unnecessary but done for the sake
;; of future debuggability.
(reset! mock-svc (component/start-system (service/consent-service
(env/get-api-config)
(create-mock-auth-checker (env/get-api-config))
{:type :mockstore
:config temp#}
{:env :dev
::http/join? false})))
;; Pull the servlet function that is used for testing out of the newly created system.
(let [~sym (get-in @mock-svc [:consent :service ::http/service-fn])]
(try
[email protected]
;; Shutdown system.
(finally
(component/stop-system @mock-svc)
(reset! mock-svc nil))))))
@ariel.silverman, :thumbsup:. I’ve done something similar in the past but leveraged a fixture.
I also had a fixture implementation but ended up abandoning that approach because I want to dynamically change behavior of the mock datastore based on test specific scenarios and realized that fixtures do not allow for arguments and it just seemed a bit clunky.
thank you for your help and for taking the initiative to write a guide on pedestal on testing. 🙂