I write a Google Chrome Extension that uses Socket.io capabilities. More precisely, it's an AngularJS app with angular-socket.io on board.
I allow users to set up socket.io server address and port in the options page. Everything works fine until a user wants to change the address because I don't know how to reset the Socket.io connection. Ideally, I would like to close previous connection and reconnect with new connection without restarting the app (remember, it's an Chrome Extension, I cannot restart it by itself).
So my question is: How to reset the Socket.io client connection and reconnect with new DSN?
PS. I'm using socket.io-client#1.3.6
You are using angular-socket.io, so you inject socket.io (with a given config) as a service into your angular app. Assuming your service is called socketIOService you can do following:
Disconnect on client-side with socketIOService.disconnect();
Reconnect with socketIOService.connect(SERVER_IP, {'force new connection': true});
Related
I have made an application that uses a WebSocket. I want to run this application on a PLESK Server, but I get this error message 'WebSocket connection to 'wss://sub.domain.com/' failed: Error during WebSocket handshake: Unexpected response code: 404' when I visit the website.
After reading a few blogs, I came to the conclusion you have to adjust something in the NGINX settings, but this also appears to have no effect, or I have to do it wrong, that is also possible. (Another blog)
At the moment our API is installed on a subdomain (with the NodeJS add-on in plesk) and it also works. As soon as I start up the files locally I can connect to the WebSocket and the API so it must be up to the PLESK Server I think. At this moment only the NGINX 'Proxy mode' is off and the 'Additional nginx directives' empty.
Perhaps one of you is familiar with this problem?
I am new in WebStorm. I have got a sample application that consist two projects: client(angularJs) and server (node.js).
When I start server app.js (api that return json), it listening port 7200
Wnen start client (AngularJS app) index.html, it works on port 63342
But the api call from client to server does not work. because client ask url
$http({method: 'GET', url: 'api/maa'}).
http://localhost:63342/quickstart/src/client/api/maa, but server works on port 7200 (http://localhost:7200/api/maa).
How to fix this, it is possible to launch both server and client on same port?
Sure. You can even start both using the same run configuration. Node.js run configuration has a 'Browser/LiveEdit' tab that allows to launch the browser and debug the client code. Check the 'After launch' checkbox there, specify the URL of the server your front end is served on (http://localhost:7200) and enable the 'with javaScript Debugger' option
I am having the following problem. I will describe 3 use cases - two which work and the other one which doesn't.
I have an AngularJS client using SockJS with STOMP. In the backend I have a Spring application. Client is in domain domainA.com, backend is in domainB.com.
var socket = new SockJS(("http://domainB.com/myApp/messages"));
stompClient = Stomp.over(socket);
stompClient.connect('guest', 'guest', function(frame) {
...
}
In the backend there are Cors filters and the Cross-origin calls are possible. All works fine.
Use Case 1. Client domainA, Server domainB
My application is unsecured on the backend side. I subscribe like below:
stompClient.subscribe('/topic/listen', function(message) {
showMessage(JSON.parse(message.body).content);
});
All works fine.
Use Case 2. Client domainB, Server domainB
My application is secured on the backend side with Spring security. Authentication is done through a form - username and password. Nothing uncommon.
In this case the client is on domainB.com, same as the backend. All works fine, the difference is that I use a different subscription method:
stompClient.subscribe('/user/queue/listen', function(message) {
showMessage(JSON.parse(message.body).content);
});
in order to benefit from getting the principal from the security session. All works well. No issues.
The JSESSIONID cookie is added to the connection request in new SockJS(("http://domainB.com/myApp/messages"));.
Use Case 3. Client domainA, Server domainB
The application is secured the same as in UC2. However, the client is now on a different domain.
The JSESSIONID is NOT added to the connection request. The connection to websocket in Spring is unauthenticated and redirected back to login page. This repeats and makes it impossible to connect.
Why is the JSESSIONID cookie not populated with the websocket requests in this case?
Cheers
Adam
As part of SockJS protocol, a http GET is sent to websocket server for negotiating the supported protocols. It's done using XmlHttpRequest which won't add any cookies stored for a different domain than its own domain the web application and scripts are served due to same-origin policy implemented in every modern web browser.
You should resort to a way of circumventing the same-origin policy.
I think you'll find the answers you are looking for here : http://spring.io/blog/2014/09/16/preview-spring-security-websocket-support-sessions
the trick to implement a HandshakeInterceptor
I have successfully implemented SignalR into my project using hubs. Everything works fine in every browser. The only problem i have is with IE7. By design IE7 only allows 2 simultaneous requests to the same domain.
The solution for this problem is using a subdomain for opening the connection to SignalR.
In your first browser tab you can use for example channel1.domain.com and in your second one channel2.domain.com, and so on.
$.connection.hubs.url = "channel1.domain.com"
Now the problem is that in a request to the subdomain the cookies don't get send and obviously i'am not authenticated. (I'am using Forms Authentication).
Do i have to change the way I authenticate my users. Or maybe somebody can give me an alternative solution.
You should make sure your cookie mask includes a subdomain (eg set your 'cookie domain' to ".domain.com" instead of the default, just "domain.com").
That way subdomains will inherit the parent domain cookies.
I have a Silverlight client calling a WCF Service on an IIS web server. It uses the default basicHttpBinding setting for the calls. My client code has the usual Visual Studio generated proxy that is generated when using the 'Update Service Reference' menu option.
Does every call to the service using that proxy use the same connection? Or does it create a connection each time a call is made and then close it down once the reply is received? As the client is actually making a SOAP call over HTTP I just assumed that every service request had a new connection created but I want to check if that is the case?
(I need to know because if it creates a new connection each time then each request could end up at a different server because there are several servers being load balanced. It is uses a single connection for the duration of the proxy then I can assume they all end up at the same machine and so cache state information for better performance.)
You have to differ between connection and session. Connection allows you calling the server. Session allows you maintaining state among subsequent requests from the same client. Application session for example allows using server side caching. First of all BasicHttpBinding does not support session.
HTTP 1.1 specification describes that each connection should be opened as persistant. When you call first HTTP request to a new server, a persistant connection is established and it remains opened for subsequent calls to the same server. If you do not call the server again it is closed after some timeout. Persistant connection openning and closing is handled internally and it is fully transparent to developers.
Persistant connections are used by all browsers and HTTP APIs including .NET HttpWebRequest and so all HTTP based bindings. You can demand that new connection is created and closed for each request/response by creating custom binding with HTTP transport channel and property KeepAliveEnabled set to false. It will add additional overhead because new TCP connection will be established for each request/response. Establishing TCP connection is time consuming operation.
Persistant HTTP connection is not related to WCF application session. WCF session is by default handled between single service proxy instance and single service instance. All subsequent calls from the same proxy instance are handled by the same service instance (PerSession instancing). WCF application session is built on top of any other session - connection, security, reliable. BasicHttpBinding does not support any of these session types so it can't use WCF application session (and PerSession instancing). Each request for service exposed on BasicHttpBinding is by default handled by new service instance (PerCall instancing).
By HTTP specification the client should be able to open only two concurrent persistant HTTP connections to the same server. Persitant HTTP connections are shared for all service proxies calling the same server from the same client machine in the same period of time. Moreover single proxy instance can call the service from many different connections if long period of time elapses among calls. Those are reason why persistant HTTP connection can't be used as connection session. HTTP is not connection oriented - it only allows reusing connection for performance reasons.
The inactivity timeout of persistant HTTP connection in WCF is 100 seconds. I have found this timeout by measuring in Procmon. I have unanswered question about setting this timeout to different value.
When you are using load balancing you can't also rely on connection. The persistant HTTP connection is opened between client and load balancer. But it is responsibility of the load balancing algoritm to select processing server. In case of BasicHttpBinding it can be simple Round Robin because processing servers will not use any kind of session. In case of session oriented binding you have to use some algoritm with session affinity (sticky sessions) which will forward all requests from the same session to the same server so the same service instance can handle them. But it is not the case of BasicHttpBinding.