I have a situation where I need to know that client system has shut down manually or due to power failure (irrespective of same LAN or wide network).
I need to know that after logging in to my application (web), client forget to logout and shut down his system manually or due to power failure.
I'm storing logged in users status in a HashMap not in DB and removing when clicking logout button....
If system got shut down without logging out that is not removing from the HashMap. Is there any event listener in Java to catch client shut down status?
How can I achieve this scenario, is this possible?
I'm using Vaadin 7.4.3 as a framework for my web application.
Add a session destroy listener to your web application and remove the user there. The session destroy listener will be called when session expires. Actually you should implement the logout button that way that it invalidates the session so the only place where you need to remove users is this session destroy listener.
Related
Heads up: flask-socketio sessions are not User Sessions mentioned below.
I'm restructuring my React app to handle multiple User Sessions defined by a string in the URL. Whenever a browser tab/window connects to the server with the User Session in its URL, I will record it as a connection of that User Session, and multiple connections of the same User Session will be stored in a list.
I found request.sid might be the right thing to identify these connections I mentioned, and I can add the value of request.sid to the list whenever a new connection from a browser tab/window is built. Each tab/window is assigned a different such sid, i.e. socketio session id, and multiple socketio session ids belong to a single User Session of my definition.
However, I don't know when a browser connection is lost due to internet disconnection. Usually, it's handled by heartbeat mechanism, and flask-socketio already has a heartbeat built in, so I'm wondering whether I can catch an event when the built-in heartbeat finally exceeds the expiration time, so that I can go ahead and delete the sid from the connection list.
Any ideas/suggestions for me? Thank you in advance!
You can listen to the disconnect event:
#socketio.on('disconnect')
def client_disconnected():
# remove request.sid from your application state
I have set the session timeout in my WebSphere as 3 Mins (Consider.Actual timeout I have set is 30 mins).I have kept my application open and just moving my mouse over the J2EE application and making some keypress which will not submit any pages.Even after 3 mins, the session of the application is retained.I need to confirm how the session is retained when some mouse move / keypress happens ? No request is being sent to server or no page submissions has been done.
The session timeout for my application is maintained only in server.
Thanks.
This sounds like it's due to WebSphere's use of the LTPA token for authentication. In summary:
When the web session expires a users credentials are not expired (you
are not forced to re-login). This is due to the WebSphere
implementation of LTPA tokens and more info on this is covered in the
IBM documentation.
When the LTPA token expires the users credentials
are expired (you are forced to re-login).
The web session timeout is
relative to user activity. That is, it resets to 0 when user activity
is detected.
LTPA token timeout is not related to user activity. It
will timeout after the amount of time from creation date no matter
what user activity is going on.
From http://www-01.ibm.com/support/docview.wss?uid=swg21078845:
Question 3
I want to force my users to re-login after a set "inactivity timeout" period. How is WebSphere Application Server supposed to work with regard to session timeouts and LTPA timeout.
Answer 3
See the answer to this question in item 9 of the following developerworks article:
http://www.ibm.com/developerworks/websphere/techjournal/1003_botzum/1003_botzum.html
From that link you learn:
9- I want to force my users to login again after a set "inactivity timeout" period. How is WebSphere Application Server supposed to work with regard to session timeouts and LTPA timeouts?
The WebSphere Application Server LTPA token expires based on the lifetime of the login session, not based upon inactivity. Thus, the WebSphere Application Server login session will not expire if the user performs no action for some period of time. However, the HTTPSession does expire based upon inactivity. If in your application you need to expire the use of an application based on idleness, you must explicitly code this in your application. You can capture when a user arrives with an expired session (really, a new session) and force them to login again if you think this is necessary. Keep in mind that doing this undermines Single Sign On across applications.
A second approach that is a slight variation on the first is to use HTTPSession.getLastAccessTime() to compute when the last client request occurred. If the time is too far into the past, you can of course fail the access and force a new authentication.
Either of these approaches can be made transparent to the application code through the use of servlet filters.
It should be noted that IBM Tivoli® Access Manager provides for lifetime- and idle-based authentication session timeouts.
Users often ask why WebSphere Application Server works this way. Why can't it timeout idle login sessions? The reason is because WebSphere Application Server is fundamentally a loosely coupled distributed system. Application servers that participate in an SSO domain don't need to talk to each other. They don't even have to be in the same cell. So, if you want to limit the idleness lifetime of an LTPA token (aka SSO token), you'd have to update the token itself with a last usage time on every request (or perhaps on the first request seen during a one minute interval). This means that the token itself would change frequently (meaning the browser would be accepting new cookies frequently) and that WebSphere Application Server would have to decrypt and verify the inbound token when it is seen to validate it. That could be expensive (WebSphere Application Server today only validates a token on the first use at each application server). It's not impossible to solve these problems with clever caching and such, but that's not how WebSphere Application Server works today.
Is it enough to cleanup on disconnect? What happens if a browser disappears before sending an explicit disconnect?
What is the recommended pattern for server side cleanup, so that the resources bound to the connection are not leaked (e.g. Namespace)?
(using gevent-socketio, if it matters)
If you use WebSockets as transport, it would automaticaly disconnect the socket on browser close.
If you use xhr-polling for example it would not automaticaly disconnect (speaking about gevent-socketio).
My approach when xhr-polling is used was:
Saving the socket session id among with logged in user id in database
On next user login detect if such a record exists
Use the stored session id in the record to disconect the unused socket since the fresh user login would generate new socket
This is not rapid solution since you may have unused sockets connected until new login is performed by the user, but it performs a kind of cleanup when the user log in.
This article may be a hint to something more creative than mine solution: http://flask.pocoo.org/snippets/71/
I am evaluating the case of using sticky sessions with Session replication in tomcat. From my initial evaluation, I thought that if we enable Session replication, then session started in one tomcat node will be copied to all other tomcat nodes and thus we do not need sticky session to continue sessions and the request can be picked up by any node.
But it seems that session replication is in general used with sticky sessions, otherwise the session id needs to be changed whenever the request goes to some other node. ref: http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind_session_after_crash_to_failover_node
Can anyone explain what is the real use of session replication if you have to enable sticky session? Because then you would be unnecessarily copying the session on each node, when the request with a given session id is always going to the same node. It could be beneficial in case of a node crashing, but then that does not happen frequently and using session replication only for that seems like an overkill.
As Mindas explained it before :
When you use loadbalancing it means you have several instances of tomcat and you need to divide loads.
If you're using session replication without sticky session : Imagine you have only one user using your web app, and you have 3
tomcat instances. This user sends several requests to your app, then
the loadbalancer will send some of these requests to the first tomcat
instance, and send some other of these requests to the secondth
instance, and other to the third.
If you're using sticky session without replication : Imagine you have only one user using your web app, and you have 3 tomcat
instances. This user sends several requests to your app, then the
loadbalancer will send the first user request to one of the three
tomcat instances, and all the other requests that are sent by this
user during his session will be sent to the same tomcat instance.
During these requests, if you shutdown or restart this tomcat
instance (tomcat instance which is used) the loadbalancer sends the
remaining requests to one other tomcat instance that is still
running, BUT as you don't use session replication, the instance
tomcat which receives the remaining requests doesn't have a copy of
the user session then for this tomcat the user begin a session : the
user loose his session and is disconnected from the web app although
the web app is still running.
If you're using sticky session WITH session replication : Imagine you have only one user using your web app, and you have 3 tomcat
instances. This user sends several requests to your app, then the
loadbalancer will send the first user request to one of the three
tomcat instances, and all the other requests that are sent by this
user during his session will be sent to the same tomcat instance.
During these requests, if you shutdown or restart this tomcat
instance (tomcat instance which is used) the loadbalancer sends the
remaining requests to one other tomcat instance that is still
running, as you use session replication, the instance tomcat which
receives the remaining requests has a copy of the user session then
the user keeps on his session : the user continue to browse your web
app without being disconnected, the shutdown of the tomcat instance
doesn't impact the user navigation.
I think the only real benefit is to be able to shut down Tomcat instances without much thinking. Especially this applies today in cloud world (think Amazon AWS spot instances) when nodes can go on and off really often. Alternative to this would be to buy a decent load balancer which supports node draining. But decent load balancers are expensive, and draining takes time.
Another scenario I can think of is a (poor implementation of) shopping cart where items are kept in the HttpSession and shutting down would require the user to re-purchase them (which would likely lead to a lost sale).
But in most cases you're right - benefit of having both sticky sessions and session replication is very negligible.
Just to clarify configuration issues on JBoss 5.X in "all" base configuration with mod_jk. Setting sticky sessions in workers.properties file
worker.list=loadbalancer
... nodes configuration omitted
worker.loadbalancer.balance_workers=node1,node2
worker.loadbalancer.sticky_session=True
does not prevent session replication. In order to switch off session replication on JBoss we need to set in $JBOSS_HOME\server\YOUR_NODE_NAME\deploy\cluster\jboss-cache-manager.sar\META-INF\jboss-cache-manager-jboss-beans.xml cacheMode parameter to LOCAL.
Usually in sticky session scenario we don't want session replication, since we do not want additional overhead connected with significant amount of I/O operations needed to replicate sessions.
In fact, if go with sticky sessions, we do not need to run JBoss in "all" configuration, we might use "default" or "standard" based configuration.
The only thing that has to be done is change in $JBOSS_HOME/server/YOUR_NODE_NAME/deploy/jbossweb.sar/server.xml:
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="YOUR_NODE_NAME">
I created an application to receive a broadcasted windows message which works fine. When I turn it into a service, install it, and start the service, the service doesn't receive the message.
The service probably must be granted access to the desktop. Do this from the Service properties, "Log On" tab, Log on as Local System account, and check "Allow service to interact with desktop".
Having windows that run as SYSTEM on a user desktop is a security issue, you should really use some other form of IPC (If all you need to do is notify the service without providing any other data, a (global) named event should be enough)
If on the other hand you want to catch notifications from windows itself about device changes, power and session events etc you don't do that with messages when you are running as a service, you get those events in your HandlerEx
Who's sending the broadcast? Unless the component sending the broadcast is running as Local System, it does not have the privilege to send window messages to window handles in different sessions.
Since all Windows Services (since Vista) run in Session 0, and almost all other components run in Session >=1, most probably that's why you are not receiving the broadcast.