jumblerg / ring-cors Goto Github PK

I'm using ring.middleware.cors with unity3d wasm.

error:
wasm streaming compile failed: TypeError: Failed to execute 'compile' on 'WebAssembly': Incorrect response MIME type. Expected 'application/wasm'.

warning:
HTTP Response Header "Content-Type" configured incorrectly on the server for file Build/MyGame.wasm , should be "application/wasm". Startup time performance will suffer.

(def ring-middle
(-> ROUTE/my-route
RING-MIDDLEWARE-JSON/wrap-json-body
RING-MIDDLEWARE-JSON/wrap-json-response
(RING-MIDDLEWARE-DEFAULTS/wrap-defaults
RING-MIDDLEWARE-DEFAULTS/site-defaults)
(RING-MIDDLEWARE-CORS/wrap-cors
:access-control-allow-credentials "true"
:access-control-allow-origin [#".*"]
:access-control-allow-headers #{"accept"
"accept-encoding"
"accept-language"
"authorization"
"content-type"
"origin"}
;; I want to add mime-types. "content-type:... "application/wasm br gz javascript" ... etc
:access-control-allow-methods [:get :put :post :delete :options])
))

Anchoring ensures that partial matches are not accepted unintentionally:

(wrap-cors routes #"^http://myapp.mydomain.com$")

http servers often handle exceptions, converting them to http responses with codes other than 200, often in the 500 range. if the exception is caught outside of the ring-cors wrapper (which is best placed on the outside), it will be returned without the cors headers expected by the client. the result is that, to someone viewing the exception on the client, the true nature of the error will be masked by a cross-domain exception. this can be particularly annoying in development, when server errors are more likely and stack traces are often propagated to the client. even in production, where exceptions should be less informative, it may result in deceptive error messages on the client.

it may be that the best practice for dealing with this annoyance is to explicitly place an error handling middleware just inside the cors wrapper.

this ticket is a reminder to not only experiment with this approach, but also to consider any alternatives that might exist.

I have the following system.components config:

(defn config []
  {:http-port  (Integer. (or (env :port) 5000))
   :middleware [[wrap-defaults api-defaults]
                wrap-with-logger
                wrap-gzip
                ignore-trailing-slash
                [wrap-reload {:dir "../../src"}]
                [wrap-trace :header :ui]
                wrap-params
                wrap-keyword-params
                wrap-cookies
                [wrap-cors #".*"]
                ]})

But when my server makes a redirect, I still get the cors error on the client side.

I'm playing around with ring and as soon as I went from testing with curl I ran into my browser complaining about CORS on GET requests. I put ring.middleware.cors to use (I think the following are the only relevant bits):

(defroutes app-routes
  (context "/swap" []
    (POST "/auth" req (do-auth (:kw-body req)))
    (POST "/renew-token" req (do-renew-token (:kw-body req)))
    (GET "/groups" [] (do-groups))
    (POST "/swap" req (do-swap (:kw-body req))))

(defroutes app
  (-> app-routes
      (cors/wrap-cors identity)
      wrap-log-request
      wrap-json-response
      wrap-kwjson-body
      wrap-json-body))

That works great for GET, but not for POST! How do I accept all POST reqs, no matter the source?

Hi, thanks for this neat library.

wrap-cors always propagates the preflight request to be handled down the pipeline. Usually, you just want to provide an empty 204. But, in order to do this, I will need to check that the request is a preflight request again in my own code, and, in any case, my response status will be overwritten by wrap-cors to a 200.

How are we meant to handle those preflight requests?