I have been asked previously this and not sure what is supposed to be the answer, the question is suppose you had an online trading page, that allows you to buy and sell stocks whereas all the stocks are constantly changing via ajax, how do you implement to check if the user/session is still active?
I had suggested to use javascript, where when the user is not keying or not moving the mouse it will prompt that the session will end, and log out the user
Second alternative, would be to put a session-timeout in web.xml whereas once the user has session timed out it will require the user to relogin.
But both answers I have provided seemed wrong. What is the proper, standard way to handling session on a dynamic page? (i.e buying airplane tickets or stock trading page?)
Can anyone provide example?
Related
I posted this question java-vaadin-14-detect-user-leave-closes-tab-f5-etc but I think I asked the wrong questions.
I want to limit each signed-in user, to just one (1) active browser tab, or UI for that matter.
Someone told me to use VaadinSession.getCurrent().getUIs(), but this list is incremented by 1 (or 2 if #Push is enabled) every time the user refreshes the page. This means I can't check if this list contains more than one (or 2).
I'm lost on this! With native java applications and a built-in login system, I can EASILY limit each user to just one (1) session. It's harder with a browser. Or maybe it isn't?
You could maybe register a UI init listener which closes all other UIs in the same session whenever a new UI is initialized?
See:
Tutorial: UIInitListener
Javadoc
On the other hand, I would also be curious to understand why you want to prevent users from opening multiple tabs.
I am developing an application(Employee exit process from a company) where a employee requesting for exit and his request would be forwarded to his primary supervisor for approval(We have a table in database where we have respective details about candidates like
employee->primary supervisor->HR Manager. So the supervisor will get an email to approve or reject the request. so depending on the reply of that mail we have to forward the request to HR for further approval or to inform the employee through mail that his request is rejected(the condition is all this should be processed automattically)..
Is there any solution that you can suggest ???
As far as I understood the aim is to develop the described system and the question is about its general architecture.
I'll try to give a couple of tips, hopefully they would help.
The primary indicator of the primary supervisor response is its e-mail reply? If its so, I think its not a good approach.
I wouldn't reply on e-mails for managing a "protocol" which is, essentially a part of the business logic of your application.
Using e-mail is totally fine to "notify" the supervisor that the employee wants to quit.
Now, as for me, you should build a server based application what will run in some container (you mention java), so take a look on tomcat, jetty and so forth.
This application will have the following logic:
The employee that wishes to quit, opens the application and gets to the screen "Report my will to quit" (I omit credentials and everything for brevity) with a button "Report".
Now, when the employee hits the report button, the system should find out who is the direct supervisor of that employee, generate an e-mail to him/her and send.
Now, this mail is a notification it should contain the information like this:
- Employee "John Johnson" has reported that he wants to quit. Please check the now the link should come. The link leads to the aforementioned system (with parameters and everything). The Supervisor now gets to the special screen where he/she has an option to agree (a button) or to disagree (another button).
If the supervisor agrees, the system generated an e-mail to HR and to the employee.
General notes:
Pay attention, everything is done within the system, the e-mail is used only as a notification mechanism.
In addition to this fairly basic functionality the system should "memorize" the state of the whole process. The states should be like "employee X has asked to quit", "the supervisor agreed" and so forth.
The system is independent of the e-mails (If e-mails go offline or something your system will still work). Moreover sometimes the supervisor just wants to enter the system and see what happens there without even opening the e-mail. The same holds for HR.
Of course this explanation is fairly basic, but I guess you've got the idea.
Hope this helps
I'm currently researching the best method of solving an issue I'm having and was wondering if you could help.
I have a user profile section in my website that I want to make a bit more secure.
I have an issue where when a user logs in, if they click the back button it takes them back to the login page but they're still logged in. How can I have it log the user out and take them to the logout page?
Thanks for your help
I'm not sure you are trying to do the right thing. Users know and use the back button, and it is helpful to them if that button takes them back to what they were doing beforehand. Having it automatically log users out breaks some basic assumptions about how web applications work, and I don't recommend that you do this.
Also, the problem is worse than you think it is. You mentioned users who use the back button, but what about users who use right-click-open-in-new-tab to open several tabs viewing your application, then switch back and forth between the tabs?
That being said, here is a way you can achieve what you want. You need to track most-recently-viewed-page in the user's session on the server. Each time you get a new request, compare against the cached value in the session and if it's not a page that could have navigated here, clear out the session and display the login page. Another way the same thing is achieved is to generate a key as each page is displayed (a large random number will do) which is passed on the subsequent request, and when any page is requested and it doesn't have the most recent key then clear the session and display the login page.
I have a Java web application which stores some data in the session. The data in the session changes as the user interacts with the application (e.g. flow is managed by a controller, each controller has several form pages, on each form page some data is updated in the session and flow goes to the next form page).
The problem is that some users are opening more than one tab to the application, each tab with a different step in the flow. At this point data in the session is messed up since the tabs share the same session (app uses cookie managed sessions).
Telling the users to use different browsers to avoid sharing the same session id (e.g. one Firefox window and one IE window) is not an option since surely at some point somebody will forget to do this and instead use tabs, thus messing up their data.
Adding some verifications that detect that another flow is requested from another tab and display a message to the user saying this is not allowed is not an option either since it pisses of the users and we don't want that do we? :D
The fact is that using another tab is useful for the users because they are more efficient in what they use the application for, so I am keeping this option. But the question now is how best to manage the one session data for the more tabs?
What I thought of, was to have the controller generate a token when it starts the flow and pass this token to each form page which in turn sends it back to identify itself. If another tab requests the same controller action when there is an ongoing flow then generate another token and pass that around.
Basically, I want each flow to have a token and inside the session I won't just keep one set of data but have a set of data for each token and then match requests based on the token.
Now the problem is that this approach will need a lot of rewritings to the application and I was wondering if there is a best practice for managing such a situation or can someone suggest other approaches. I am open to ideas.
Have you encountered this situation? How did you handle it?
This is usually done by assigning a windowId for each tab/window and passing it on each request. Jsf supports this via orchestra. Spring mvc will support it in the next version.
I recently needed this for a simple case, so I implemented it myself. Took half an hour. However, my scope was very limited:
pass a windowId with each request, and return it back for the next request. The first time - generate it.
for any attribute you want to store in the session, put a Map<String, Object> where the key is the windowId
This is exactly what Seam was created to handle. In Seam there's a concept called a Conversation which basically does exactly what you are explaining. Conversations are basically are a way to divide the Session into many pieces that can expire at some timeout. You can look at the source code for org.jboss.seam.core.Manager class to see how it's actually implemented and get inspired ;)
Depending on the complexity of your application, you may want to investigate implementing tabs within your application. This gives you wholesale control over the flow, while still providing users with the functionality they want. I'd argue it's, bugwise, the most robust solution, since you won't have a dependency on the way the browser handles sessions, minimising the number of "known unknowns".
Of course, there'll be potentially a large upfront cost to this, depending on how your application is structured. Without more information about your app, you're the best placed person to decide.
You can also try to wrap your application inside Adobe Air
And then limit your web application to be only accessable from this air. By doing this you dont need to consider the web browser fragmentation and their unique behaviour.
I develop and maintain small intranet web apps(JSP and Resin).
Some users takes so much time to complete the forms that,
when they submit, they lose all their input data because of session timeout.
Currently I prolonged session timeout to 30 minutes and
display count-down clock till session timeout on top of the page, but,
I think their must be better ways to
protect user inputs.
What is the best practices?
Addendum
Our users make several kind of reports with the web-app,
and the whole contents of each report are stored in a JavaBean stored in the session.
As suggested by some, Ajax or iframe should do the quick fix.
I now know that it is better not to abuse session with heavy objects,
but I'm not sure how best to refactor current mess.
Some people suggested to make the web-app stateless.
Any suggestion for refactoring is welcome.
This may or may not be the case with your framework, but I think that if your page just uses AJAX to call the server every five minutes (or whatever), then that will keep your user's session alive. You don't even have to do a partial save of your form this way.
Make your applications stateless on the server side. You can include any state you need to maintain in hidden input fields. If security is a concern then you can encrypt the data before putting it in the field.
An example is putting something like this in your form:
<input type="hidden" name="user" value="bob" />
<input type="hidden" name="currentRecordId" value="2345" />
<input type="hidden" name="otherStuff" value="whocares" />
The main advantage of this is that your web app can do everything it needs to with just that page. It doesn't need any session variables because everything it needs is in the page it just received. Now it doesn't matter how long they take because there is no session to expire.
A secondary advantage is that it reduces the load on your server because it isn't polling your users periodically.
I've only recently needed to look at solutions to this problem.
The direction that looked most promising was using AJAX to periodically check if data was entered, and send it to the server. If the browsers running in your company support AJAX, this is one possibility.
Another possible solution could be to split the forms up, so that each section is small enough to be filled out and submitted within the session timeout.
If you are creating an application for a limited number of users (e.g., a company intranet) and you don't want people to have to keep logging in all day or have them lose their input information when sitting for extended periods of time, you can keep sessions open indefinitely only for people that have their browser open to your website without setting the session timeout to not expire. As soon as they close the website then the session will expire as normal.
What you need to do is add a hidden iframe somewhere on the page. Have the iframe point to a simple html document served by your app server that has a meta tag in it to refresh every 29 minutes (for a session that expires in 30 minutes). This way, as long as the person has your web page open, their session won't expire. However, when they navigate away from your site it will expire as normal. You get unlimited session lengths without the downside of sessions that grow out of control.
I successfully deployed this solution in an enterprise environment at a previous place of employment. The web app replaced an old green screen application and it was unacceptable for them to go to lunch and have the application expire on them, for example.
Let me know if you need more of an example.
I'd recommend looking into a stateless alternative (something that does not rely on session attributes) to what you're doing.
We may be able to help more if we know what exactly it is you're relying on sessions for.
You could store the data in a cookie every once in a while, use Gears as a temporary storage (if the data is complex or requires more than 4K storage) or send the temporary data to the server every n second using AJAX.
Umm..
What about displaying a prompt to the user about the session about to be expired -- save data (say 5 min before), so that they can save the data. This way they know what they have to save and in case the session really needed to be expired, it will be done afterward if they don't respond.
This is an alternative in case when you want to avoid a continuous ping to server using AJAX.
Don't use the session object. This is a cause of all sorts of usability problems - as you are discovering.
It's my golden rule of web application development: don't use the session.
Having said that, use it sparingly for things that just can't be done otherwise.
I would trigger "after a Ajax check that the session is expired" an popup form in a modal window that the User must sign in again, This popup overlay would be over the current page/form. So the data wouldn't be lost.
P.N Update the session token if U have one... in a hidden field.