session handling in struts 2 - session

I am stuck with a session handling problem for past few days.
I am working on an application where an user logs into his account and can register there details or change them. How to manage sessions in this case. I mean how can i access the attribute of a session in different action classes?
Also when i click on log out and after that i press the back button given in the browser it goes back to the previous page and user can change their details which should not happen. Please help !!

The back button "issue" is because you have not disabled page caching.
Sessions data is available in actions via the SessionAware interface.
Sessions are per-user (more or less, actually per-conversation, and how that's implemented varies somewhat across browser versions), not sure what you mean regarding concurrent users.

Related

Does it ever make sense to have two concurrent sessions in the same browser?

I was wondering if it ever would make sense to have two concurrent sessions in the same browser? There could be two types of cases with this:
1) A user opens a browser window and logs in as user A, starting session 1. Then he opens another browser window (in the same browser) where he logs in as user A, but starts a different session, session 2.
I know that this is often not possible in many browsers, as one session cookie is set for the entire browser. However, in some browsers, it is possible to have multiple sessions in that manner.
2) This is similar to 1, except that the second time the user logs in, he logs in as user B, starting session 2. So now you have a person logged in as two users in the same browser.
Finally, allowing these things doesn't seem like the best security practice and neither does it seem to be practical. What do others think?
First thing First as the your Assumption is wrong. First of all you have to understand that when Single website is accessed from browser have single session and its not possible to simultaneously run different session of same web Browser.
It seems you have wrongly understand the working of Private Browser. Private Session are not made not to share information cookies and data with other public session and vise versa also. As soon as you close the Private Session all the Cache, Cookie and other things are deleted for forever.
I have not seen any web browser supporting the Multiple session of browser.
But an alternative approach is available i.e you have to create different Web Browser Profiles which can help you as each Profile data is maintained separately and have no conflict with other sessions.
One possible scenario currently I am facing requires allowing multiple user sessions from the same browser and I have not been able to find a proper solution for it yet.
We are using Yii framework. Currently we have two kinds of users i.e customers and admins. Both login from the same login form and use same session name and variables to store session information. Only based on type column in user table(customer or admin), the user is taken to appropriate views. In one of admin views(pages), there is an option for admin to log in as any of the users and propagate through the user's view in an iframe. The problem is that when the admin open two tabs and logs in as two different users, the session information of one overwrites the other and we start getting session related issues.
Can anyone suggest me a proper way to handle these kind of issues. I have searched a lot on trying to handle this with multiple sessions, but have not been able to find a proper solution yet.
There's nothing to "provide support for" here. One browser cannot hold more than one session, since it only holds one unique cookie per site, regardless of window. If a browser actually has a mode in which it supports holding two separate identical cookies per site, then it's the same as if the user logged on from another browser or another machine. That certainly should work; i.e. you should not try to subvert that behavior. A double session inside the same browser is then just a specific instance of this multi-session behavior, nothing special.

store data for bookmarklet

I am making a bookmarklet, which calls a Google App Engine app. The GAE app uses login information, which I want to store in bookmarklet, so when user first clicks bookmarklet,it asks for login info, but from next time onwards it automatically supplies it.
The difficulty of a bookmarklet directly storing data is that it can only store data in cookie or in localStore, both of which "belong" to whatever page it is currently on. That means it won't work again the next time you use it on a different page, and it also means the page you are on can access the data, which is generally very bad for security.
There are two basic ways your situation is generally handled. The two main ways are:
1.) The application used keeps the user logged in with a cookie. The login information is not stored in the cookie; only a session ID is. This is like when you return to many popular websites, you don't have to log in again. Very often these types of bookmarklets open a small popup for the user which contains a page from the app. If the user is not logged in, the app prompts the user to login first. The bookmarklet in fact knows nothing about being signed in or not.
2.) Each bookmarklet is custom created for each person. So my bookmarklet would be different than yours. The difference is simply that mine will contain my login info in the code, and yours will contain your login information in the code. In fact we would each have to login to the app first before we can get our own personalized bookmarklet.
Generally, option 1 is better and easier and more secure.
If I understand it correctly,this Might help you. http://ajaxian.com/archives/whats-in-a-windowname
It allows for storing data in windowname in JS. Allowing for access of up-to 2 MB of data (A lot more than cookies can hold) and I believe can be used across tabs...

asp.net - maintain session while debugging and rebuilding solution?

I'm writing an asp.net Web Application. I wrote a login page that authenticates a user and stores their UserID in the Session["UserID"]. Every page in the web application will check for a valid Session["UserID"]. If not valid, then redirect the user to the login screen.
This works great, but it's slowing down my ability to debug every page on my website. Each time I make a change to a *.cs file, I need to press F6 to rebuild my solution. Doing this destroys my session, which means I need to go back to the login screen, type my username and password, click to the page I was working on, do my tests, make code changes to my code, and repeat.
Is there a way to keep my session alive everytime I re-build my solution so I don't have to go to the login page every single time?
Unfortunately, I don't know that you will find any way around this limitation. Every time you build your project, you are going to trigger a restart of the web application. Even if you were to use a persistent store for keeping sessions, you're going to lose the session cookie being set in your browser.
You could add a "remember me" feature to your app. You'd need to do a little reimplementation, in order to keep the information about the current user authentication in a data store that is less volatile than ASP.NET session state. Also, you'd store the index to that information in a cookie that is more persistent than a session cookie.
That's the best I can think of, or at least it's the best I can think of without some significant extensions to the .NET security providers. However, take it with a grain of salt -- I've never tried to solve this particular problem before, and I hardly consider myself an expert in all things ASP.NET session-related.
The reason why you lose your session is because your application is restarted when you write to the application folder. In fact the same thing happens when you publish your application, every user currently logged in will lose their session.
This is intentional because they have no way of knowing that the DLL's you were using in your page are still there or not. So instead they monitor the folders themselves and trigger a restart when you write to them.
There is no workaround for this. It's in fact a feature that saves you time (most of the time), imagine tracking down memory corruption errors because the pointers moved around in your code!

Timeout on custom membership provider in asp.net 4.0

I have implemented custom membership provider in my project. i kept one flag on database to get the users online. i want to reset this flag on the log out, i can do this if the user log out properly . I have to reset the flag on database even if the the browser closed directly or on any machine failure or normal time out, any tricks on membership provider to solve this. experts am waiting for your answers!!!!!!!
Thanks.
just put a field for users like IS_LOGOUT_BUTTON_PRESSED typeof(bool) default false
if the user click LogOut set it TRUE.
if the user closes browser, it will stay false. Then you can see what user did.
I am afraid that you are tilting against windmills.
You will notice that the sql providers implement the 'users online' by simply updating last activity in most all provider methods (and subsequently the stored procedures) and then using a predefined 'online time window' to determine if the user may still be online.
To implement an authoritative 'is_online' flag would require that you have complete control over the user's means of starting a session and ending a session, which you do not and can not do due to both the nature of the browser ui and the way that sessions and ticket expirations are bumped.
So you can never really be sure whether a user is online or not, rendering any efforts you have made to track this metric unreliable.
And unreliable data is often of less value than no data at all.
I am quite certain that you will find nothing but frustration in attempting to apply an absolute, as described in your question, to the stateless and freeform nature of sessions and tickets.
Sorry I have not better news.

Firefox extension to log out user after the page has been closed

I am writing my first FireFox extension and I have some questions. Maybe someone can help.
I have a website which requires login. The sign-in is one user per login type. So if I am logged with the username "tom" from one PC and go to other PC and try to login with the same details, it fails. When I click the log-out button from my authenticated page, the new location executes a PHP function to log-out the user (updates the "logged" status of the user in MySQL). The problem is that if a user is logged in from his work desk and surfing the page then suddenly he gets a call by a friend to quickly grab lunch in his break and has to meet him in short time, he just clicks the X (close) button from Firefox, forgetting to press the log-out button so the status of the logged is still 1. Later on, if he wants to access the page again from home, he won't be able to log in.
So, I need to grab the "close" event from firefox somehow. I am thinking about looking for the ones that contain the "website.com" domain only. Then, if a tab is closed or the main window of Firefox is closed, send an unique key, and the username to that URL that logs out the user and the problem may be solved. I don't know if this is possible. Please post any idea (followed by code if you can) for this extension to be built.
Thank you.
By design, this is wrong.
If a user's PC crashes (harddisk failure, power failure) your plugin won't be able to log out the user. And so, the user won't be able to login on any PC.
--
Let's revisit the premise,
a. why does logging in from another PC need to fail?
b. How about invalidating the login from the previous PC (log out) when the user logs in to another PC. THis is kind of like how chat applications like Yahoo! Messenger work.
From your answers, here's what i would suggest: if the user is logged in on another PC, warn and present the user with options:
cancel logging in
forcibly log out the other user and proceed to logging in
Logging the user out after a certain time of inactivity is the (application or web) server's responsibility, not (only) the client-browser's. This is called a session timeout.
You might be able to avoid the timeout by a browser implementation as you describe it, but this should not be the primary solution.
Here's an off hand approach you might take:
In your case I would include a timestamp in the table where the 'locked' state is stored. Every time a user does an action that timestamp is updated. When you try to login again ad the timestamp is older that a certain threshold (e.g. 15min) your login code should silently logout the previous user.
In order to receive a notice about the tab being closed, you'll want to do something like this sample code. However, instead of listening for load, you'll want to listen for unload.
When you do end up getting notified about unload, you'll have to do a request to the logout page just like the web application does. You can figure out what the location of the document that is unloading is by checking aEvent.originalTarget.location.href. Note that aEvent.originalTarget will give you the document object of the tab that is closing. You'll then want to use an XLMHttpRequest for this in your event handler.
You could use ajax that would ping a page on the site - all the session info will be passed and you can verify that the user still has an active browser/page open. If Firefox crashes it won't be able to ping the website anymore and the session could time-out after 15 minutes. I think that allowing a forced logout on another sign-in would be best. Usually when I leave work at the end of the day I wouldn't close all the programs or logout or anything - just lock my computer to prevent anyone from using it. Next morning I come back with all my programs still running so I can continue where I left off.
BTW, Yahoo Web messenger probably uses some form of session-based cookies. That is, cookies are stored in memory and are gone when the tab or browser are closed.
Just enable to the user to re-login from another machine. And if you get a request from the user on first machine, ask him to re-login too. So you get a single logged in user at a time.

Resources