My understanding is that that's a client limitation, that a browser will refuse to make a websocket connection to a server other than the one that served up the original web page, as a protection against malicious scripts that make it into page via whatever attack vector.
Tim On Wed, Jul 29, 2020, 9:47 AM Christopher Pisz <[email protected]> wrote: > I have a process that runs in California that wants to talk to a process in > New York, using Stomp over Websockets. > > Also note that my process is not a web app, but I implemented a stomp over > websocket client in C++, in order to connect things up to my backend. Maybe > this was or wasn't a good idea. So, I want my client to talk to the server > and subscribe, where their client pushed messages. > > I was implementing my own server when I saw that ApacheMQ supported Stomp > over Websockets. So, I started reading the docs. > > It says: > > One thing worth noting is that web sockets (just as Ajax) implements ? > > the same origin policy, so you can access only brokers running on the > > same host as the web application running the client. > > Is this a limitation of the server or the web client? > > With that limitation, if I understand right, the server is not going to > accept websocket connections from a client, of any kind, that is not on the > same machine? > > I am not sure I see the point of that... > > If that is indeed its meaning, then how do I get around it in order to > implement my scenario? >
