CORS/Cross-Origin Resource Sharing headers support

[ceefour]

Configure CORS headers in the response, e.g. :

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: HEAD, OPTIONS, GET, PUT, POST, DELETE, PATCH
Access-Control-Allow-Headers: *

So that the web_stomp plugin can be used from HTML5 app originating from a different host. For example, a webserver serving from www.host1.com can connect WebStomp to stomp.host2.com.

The above headers are just examples, it should be configurable:

1. disable CORS (default)
2. enable CORS for all clients (this is most useful). To do this Access-Control-Allow-Origin: should match whatever Origin sent by client (if available), or if missing then *.
3. enable CORS selectively / customized headers (optional)

Related to https://github.com/rabbitmq/rabbitmq-management/issues/3

[mmoser-rivermoss]

We are hitting this issue. It looks like it will be fixed in 3.6.0. Is that true? Is there an ETA for 3.6.0. Thanks.

[michaelklishin]

October.

[essen]

It looks like SockJS-Erlang already adds the headers for the relevant transports. Perhaps there's a bug, or a header is missing?

Do you perhaps know which transport is failing, or have a small example I can try to reproduce?

[essen]

Tests yesterday showed that SockJS-Erlang fails to add them. I will investigate.

[essen]

Alright it was my tests being incorrect.

SockJS-Erlang, today, in master, does send the CORS headers for XHR transports. It enables everything by default, and there doesn't seem to be a way to configure it otherwise. Is that OK or do we want to add a configuration option to disable it? I'm not sure anyone ever would.

That said, it also works for me in the current version. @ceefour Can you provide me with some more details as to what error you get and/or what you expect?

[essen]

Or @mmoser-rivermoss also. :-)

[michaelklishin]

We can't reproduce yet => clearing milestone.

[Shmee007]

I'm having the same issue as @ceefour

"XMLHttpRequest cannot load http://rabbitserver:15672/stomp/info. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://website.com' is therefore not allowed access. The response had HTTP status code 404."

Running Rabbit v3.5.3 on Windows Server 2012 R2 Standard, connecting as "guest" with no config file set up, so all defaults.

Request Headers: GET /stomp/info HTTP/1.1 Host:rabbitserver:15672 Connection: keep-alive Pragma: no-cache Cache-Control: no-cache Origin: http://website.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36 Accept: / Referer: http://website.com/ Accept-Encoding: gzip, deflate, sdch Accept-Language: en-GB,en-US;q=0.8,en;q=0.6

Let me know if there is more detail I can provide.

[Shmee007]

After some more reading I corrected the port (I used the management port by mistake) and changed from using "guest" account. Now I keep getting "ERR_CONNECTION_RESET"

So the CORS issue appears to be due to permission restrictions on the newer versions of RabbitMQ which I'd not picked up on.

[michaelklishin]

@Shmee007 per @essen's comment, this is resolved in 3.6.0, which will be released in late November.

[Shmee007]

Thanks @michaelklishin for the clarification, I was not sure after reading the message chain.

[ceefour]

I also have no problem with WebStomp-CORS using 3.5.4, accessed by remote client (as long as I use other the "guest" user, due to loopback restriction, but this is not specific to WebStomp).

So it seems this is fixed sometime betwen May 2015 and v3.5.4.

[essen]

Closing, as everything looks OK to me on master (future 3.6.0).

Current output:

$ curl -i http://localhost:15674/stomp/info
HTTP/1.1 200 OK
server: Cowboy
date: Tue, 10 Nov 2015 16:15:25 GMT
content-length: 79
Content-Type: application/json; charset=UTF-8
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Cache-Control: no-store, no-cache, must-revalidate, max-age=0

{"websocket":true,"cookie_needed":false,"origins":["*:*"],"entropy":1008471700}

[makasim]

I got that problem as well. For it was because the old version of sockjs library in the example from here.

I changed:

-<script src="//cdnjs.cloudflare.com/ajax/libs/sockjs-client/0.3.4/sockjs.min.js"></script>
+<script src="//cdnjs.cloudflare.com/ajax/libs/sockjs-client/1.1.2/sockjs.min.js"></script>

and fixed the problem

[michaelklishin]

@makasim thank you. We can't edit CloudAMQP blog posts (@carlhoerberg can, though, if we ask nicely) and SockJS is not really relevant in this day and age thanks to the "raw" WebSocket endpoint but feel free to update our Web STOMP examples repo, test it and submit a PR.

Web STOMP documentation is also open source ;)