websocket session is wrapped in a http session and so when the http session timesout the websocket session also times out.
However, when only the first call is a http call which is based on session cookie and the rest of the time it is a direct established connection,
how does the connection ever close in case of a timeout?
Scenario - We have a reverse proxy that manages the validation check on the sessions. This means it intercepts each call and checks for the validity of the session.
In case the cookies have expired, it returns a 401.
Since I have integrated websockets to this system, the initial websocket call goes through this reverse proxy with a valid cookie, upgrades the request to websocket and thereafter
keeps sending messages directly. The reverse proxy is not aware of these direct messages sent over WS.
Now when the http session expires, the other calls being made to the system get a 401. However the WS connection above does not know about it at all and continues to send/receive messages.
In case of a logout, an invalidate is called on the http session and so all the bound objects are notified and I get a SessionDisconnectEvent. However in case of timeouts I have no indication at all.
How should I terminate the WS connection in such cases?
Stack - spring + sockJS + basic stomp
My observations are that all the websocket sessions that are bound to the http session are not terminated in case of logout. Only the one that initiated the logout gets the SessionDisconnectMessage.
In case of timeouts, there are no indications at all.
To handle timeouts, I make a call to the server soon after I get a message at the client side and look for a 401 on this call. If it returns a 401, I initiate a session close on the client side.
To handle logout, I maintain a map of the http session id and all the websocket sessions associated with it. When I receive a disconnect on any of the websocket sessions, I terminate all the other ws sessions associated with that http session.
Related
I have written WebSocket server with token authentication where the client connects as:
socket = new WebSocket("wss://websockets", ["hub", token] )
It uses subprotocol to squeeze auth token within headers.
On the server side I intercept this header key and authorize the request which works great - the client connects ok and keeps the connection open.
When token is not supplied, connection is rejected - great!
So in the typical use case: chat application, the user logins and gets authorization token to open the connection. Once connection is opened the client sends message to the server and the server sends that message to all connected clients.
So, so far I understand that the opening connection to the server and sending message to it is secured. What happens when that message is pushed to all connected clients? I don´t need to be concerned about authorization of incoming messages (to the client) since the client needs to be connected and therefore authorized to receive those messages right?
I have an unknown App consuming my Spring webservices.
The app set a timeout to every webservice calls.
The server regardless of the app timeout keeps processing.
Is there a risk of any other webservice call in receiving a misresponse (the response to the timed out webservice call)? How does Spring manages this? Doesn't HTTP protocol take care of this, given that each connection channel is open for a particular call to webservice and if broken there shouldn't be possible to retrieve the response?
As a developer, you should try to make all possible HTTP requests to your web server to be idempotent. It means that the client side has to be able to retry the failed request without new possible errors due to the inability to know the previous (timeout) request results.
The client side should handle the HTTP client timeouts himself and (by default) should treat the timeout error as a failure. Your clientside may repeat the request later and the server side should be able to handle the same request.
The solutions may vary for different tasks depending on complexity (from an INSERT statement to the database or scheduling a new CRON job avoiding duplication).
I have websocket connection between my server and client that should be kept alive until client close it. When opens connection client should authenticate himself by sending first message with token. If for some period of time after spawning websocket handler will not receive such message it should terminates. How to implement such timeout?
NOTE: idle_timeout option is not suitable as I need timeout only for first message.
Just start timer in your websocket_init callback on your own.
If user authenticate before timeout, just ignore it, you can achieve this by updating the state when user authenticate himself.
erlang:start_timer documentation:
http://erlang.org/doc/man/erlang.html#start_timer-3
I found golang context is useful for canceling the processing of the server during a client-server request scope.
I can use http.Request.WithContext method to issue the http request with context, but if the client side is NOT using golang, is it possible to achieve that?
Thanks
I'm not 100% sure what you are asking, but using a context for sometime like a timeout is possible for both handling incoming requests and outbound requests.
For incoming requests you can use the context and send back a timeout http status code indicating that the server want able to process the request. It doesn't matter what the client sends you, you get to decide the timeout on your own with the server.
For outgoing requests you don't need the server to even know you have a timeout. You simply set a timeout and have your request just cancel if it doesn't get a response back in a set time. This means you likely won't get any response from the server because your code would cancel the outgoing request.
Now are you asking for an example of how to code on of these? Or just if both are possible?
I'm writing a web client that needs to deal with lost connection.
If you are connected to a server using HTTPS and Internet connection drops, will the server lose the session information?
Once Internet connection is restored, does the client need to re-login to the server or does it depend on the server?
Usually the server determines how long a session lives (by defining a session timeout) and how a session (if at all) is persisted between single requests. The server sends a cookie with the session information (a session key) back to the client, so when the client sends the next request including the session cookie, the server knows which session to use.
Having said is - there is no information between two requests, whether the internet connection was lost in the meantime. As long as the server still has the session and the client still has the corresponding cookie, everything should work as expected.
On the other hand, even if there was no interrupt in the connection at all and both server and client were up and running, but without talking to each other (i.e. without requests), the session might be lost because of a simple timeout on the server side.
So on the server you might receive requests for resources that are secured or need a certain session state - and there is no such session. And on the client side you always might receive responses that indicate that a login is necessary.
Both cases must be implemented properly.
The HTTP protocol itself is stateless i.e. each request is served as is without any relation to previous of future requests.
To overcome this you can use client Cookies. Your cookie can keep a session state identifier which can be sent back to the server after a connection drop to resume the previous state.
In addition to that you can build a session management module which handles session persistence.
first it depends on the type of session you are talking:
ssl session
This can cause an shortend renegotiation. If the Server support it.
That mean it save CPU time.
http sessions
here it does not only depend on the server but also on your web page code.
For example if the session drop's while delivering the page conntent.
The servlet receive an connection reset during flush and may invalidate the session.
Also id depends if the session is bound to the ip adress. Than it depends if the
new connection use the same ip adress.
There is no simple answer as you maybe expected. Since it depends on to many points.
As the others already stated you can "persist" a connection by using a SessionID, which is recommended to be stored in a cookie. Most of the modern Environments like PHP and ASP.NET use this mechanism which can deal with lost connections.
Please refer to https://www.owasp.org/index.php/Session_Management_Cheat_Sheet for security considerations for implementing a secure Session Management.
Additionally what you can do with SSL is to build the Session Management using client certificates. The user is identified by the unique certificate which is issued to him. This has the advantages that the client does not have to login first. On the other hand you have to issue a client cert to every client, which might be complex.
Use cookies to store the session information, once connection is lost you can easily get the information from the cookies. call the cookies using condition i.e. if session lost call for the cookie. use Php to store information in the session and call the cookie