I am using mysql InnoDB and struts2 for developing my website. When a user want to use a product, he will be send an invoice to his inbox and with that link he can pay the money.
The problem I have to solve is: when a user opens the link in two sessions and tries to pay for both, I have to allow only one transaction. And if allowed transaction gets a problem like browser closure or some other issue, things will go into deadlock condition. I have to avoid this and allow the next transactions.
Please suggest me how to achieve this?
I think you will have to add a life time for each session to prevent deadlocks (just like in the one being used by bank's sites) and you can do that using unique sessionids. All the sessions have fix life time. Once the time is over the session is expired.
In that case if one session is active you can deny all the attempts to that session. If browser closes in between the session, session will automatically expire after its life time. Now if the payment was not done due to any reason i.e. session expire or browser closed, User can simply re-click on the link and restart the process.
Hope it helps,
Related
I have been testing a web application with Spring MVC, and I'm currently developing a editor page for accounts. This JSP page is able to edit one or more accounts, serving for different purposes. For example, a common user can edit account data on this page. On the other hand, administrator users can edit multiple accounts on this page. In terms of logic (for me), the edition of multiple accounts to an administrator user works like this:
The user selects a list of accounts.
The list reaches the controller.
The controller stores the list of accounts.
The controller directs the user to the edit page.
The user fills out the editing form.
The form is sent to the controller.
The controller retrieves the list of accounts previously saved.
Editing form data is reflected in the list of records.
The list is deleted from storage.
My problem appears when the user does not perform step 5, and decides to do something else. Without the removal of the list from storage, the server will suffer from memory leak. It would be very important to detect the user's exit, which would cause the system to remove the list automatically.
I'm choosing to save the list of accounts to be edited on the server side to prevent it from being saved on the user side, where the user could well tamper the data.
I might as well use JavaScript to detect when a user leaves a page, but he/she may well turn off Javascript, which results in the same problem. Therefore, this is an impractical solution.
I have not yet developed the implementation of it, so I'm just projecting right now. Can anyone help me with this? Am I doing something wrong?
Is there an error in my logic, or am I leaving something of use?
OBS: I'm using Tomcat 8.0, and Spring MVC 4.1.1, with the Java JDK 8.
That's the whole purpose of session management. Your web server does it for you.
When you use Java EE or any other session technology, the server is supposed to deal with timeouts, cleaning the session objects. This happens based on user idle time. How does the server know users are idle? Because for every request sent by the browser, his session id is sent in a cookie.
Usually, the timeout threshold is a changeable period of time (usually defined at web.xml). This value may need to be tuned, based on the available network/memory resources and expected simultaneous users.
In fact, sessions+cookies are the only flexible and secure way to deal with the stateless nature of HTTP.
There are variations of this, namely, conversation or view scopes, where the user may have a session per tab. But the principle is the same: put stuff in session and get them later by session id (a cookie at client side).
Finally, you should not rely on the browser to do server stuff. This would not be reliable.
I was wondering if there was a "standard" way for handling persitent HTTP sessions in a GAE based web app. Let me explain my issues.
If I only use this.getThreadLocalRequest().getSession() to get a session, this session will be automatically invalidated once the user closes the browser.
If I go with Cookies (so the session will persist until the cookie expires or the user erases his cookies), I need to have a kind of mechanism for validating that the sessionID stored in the cookie actually belongs to a valid session. I've thought about storing a key value pair of sessionID, HttpSession in a concurrentHashMap, but now I run into the problem that this hashmap will be available only for the current instance, therefore I might run into consistency problems.
The last solution I thought of was keeping track of the session in the datastore, but it seems pretty ridiculous to me having to query the datastore each time I receive a request.
Maybe I'm totally out of the track and there's a really simple way to achieve what I'm trying to do: Http sessions that persist across browser restarts and multiple gae instances.
Thanks!
Rodrigo.
You typically use a cookie to implement remember-me. The idea is to generate a random and unique cookie for an authenticated user, store it with the rest of the user information in the database, and send the cookie to the client browser.
Now, when the client comes back 5 days later, the cookie is sent with its first request to your application. At this time, if the user is not authenticated yet, you can extract the cookie from the request, find the user in the database who owns this cookie, and automatically authenticate him as if he sent his credentials.
This solution doesn't need to modify anything to how the sessions are handled by GAE.
I've read that the play framework solves the session fixation issue by hashing the session id with the application key, but does it provide any mechanism to prevent session hijacking, or is this left up to the implementor?
The play documentation has a good section on security, so rather than duplicate, here is a link - http://www.playframework.org/documentation/1.2.4/security.
It covers
XSS
SQL Injection
Session security
Cross site request forgery
Some you have to implement yourself, others you don't.
Your specific question about session hijacking is automatic.
The session is a hash of key/values, signed but not encrypted. That
means that as long as your secret is safe, it is not possible for a
third-party to forge sessions.
No, there is no built in way to prevent the hijacking of a session as soon as one is able to capture the session cookie (through sniffing/man in the middle).
There are some ways to make it harder, e.g.:
using only https
setting application.session.httpOnly in application.conf
One approache to make it harder is:
- store the ip/user-agent/resolution/other stuff or a hash of that also in the session.. in your controller you then check if the user that accesses your site still recreates the same hash... the only real problem is with people that are using a proxy that e.g. changes the ip on the fly because of clustering.
A little trick you could try to use: (works only in recent browsers)
When a user logs in, store some stuff in a HTML5 local storage. Modify your Ajax calls to supply this information from the local storage. If the information is missing/invalid, you can invalidate the whole session. But you'll have to make sure, that the checks only get applied against requests from HTML5 browsers.
hope this helps a bit.
I am having some issues with my web application while doing a performance test with Jmeter. My question is not around Jmeter instead, it's around a simple Servlet session management behavior.
So we have a web application, where in when you request a login page, it passes back a "Session Id" in response headers and that is used for subsequent request made by browser. Session Id is passed along with username and password and if authenticated a new session id is returned and session is maintained with that session id going ahead.
This is using cookies.
Now in Jmeter we have a thread based approach for load testing. When I run threads parallely what is essentially happening is that each thread request a login page and somehow only the last thread to request login page is authenticated as I feel that subsequent login page that comes with a new session id in cookie, invalidates the old or other session ids.
This is inspite of the fact that each thread is a different session and has it's own cookie manager. It's quite wierd.
However my questions are:
Does it make sense to have session id coming with login page; I see that maybe session is created as soon as application is accessed, but is it that, what sets a new cookie with session id? This application was already written so I am just wondering.
If each thread's session id is being overriden in jmeter does that mean, that i am not able to allocate a seperate cookie manager properly? Also even if threads are different sessions is there a possibility, old session id or cookie would be discarded?
How would Server know to invalidate the session id/cookie for subsequent requests? I am sure, not basis of IP address of requestor, as different browsers would still let me open parallel multiple sessions.
Any ideas, clarifications and light on the issue would be much appreciated.
Server will just timeout the session it definitely sounds like you are over writing cookies here.
Have you tried seeing how it manages by including session ids in the url (simulate cookies being disabled in the browser) Does this work?
Has this been solved at all?
I would say that having a session id in the login page is quite unusual. Session are meant for storing data server side and associate that data to connected users. Of course, prior to authenticate the user, there shouldn't be any data server side.
I need to implement SSO between a windows domain and a J2EE web appliction.
I've been thinking what the impact of this would be on the web application's session timeout. We have a 2 hour time out.
If we implement a seemless SSO, then I think it might become confusing for the user.
The SSO will make it appear that the web application is immediately available.
I'm worried that they will start filling in forms then go for lunch (or something) and come back after their session has timed out. However, it might not be immediately apparent that this has happened, since the SSO will just sign them on again (but now with a new session).
Has anyone any experience with anything like this and how to handle it? Do we just need to implement some form of extra messaging to tell the user that their previous session has timed out and their work has been lost?
I think you definitely need to pop-up an Alert box of some kind if the user's session is reset. Get them to click OK on the message and redirect them to the home page.
Also, I think a 2 hour timeout sounds like a bad idea if you're doing it how I think you are. Do you mean the user has 2 hours from when log in to work before their session times out? Wouldn't it make more sense to have something like 10 minute timeout but with the timer getting reset whenever the user sends a new request within that session.
The timeout is not a static fixed time measured from login but rather a dynamic measure of inactivity.
On sites we hav buit with this functionality after 10 minutes or so the web page goes back to the login page (JS used) and the user can start again if they want.
If they are busy with a long process where they are reviewing results or something then check the mouse move or some sublte key like that indicating they are still busy.
Old question, but in case anyone runs across it:
Try really hard to store no state in the server session. Client, fine; back-end server persistence (like a database), fine. Just nothing in between that would get lost. When the user is seamlessly re-authenticated, they don't notice the switch. Duration of timeout becomes irrelevant.
This answer is actually more feasible now, six years later, as there are several front-end frameworks that will store your data for you. You can still use Spring Security (say) on the server, as the authentication is still there with the new session; it should regenerate your security info (SecurityContext, UserDetails, etc.) on the fly. Whatever request gets or sends data should then "just work."