5

I’m developing a system to process financial transactions received by client merchants systems & it is a replacement of existing system which we have purchased from a vendor. Client interface should invoke the user authentication & transaction processing screens from our system.

System functionality as follows,

  1. Receive input parameters from the merchant’s site
  2. Validate it
  3. Authenticate users (users are registered with our system & we should invoke our login screen)
  4. Process transaction
  5. Return status response to merchant

One the response is received client should validate the transaction data from the values reside in the session.

System overview can be depicted as follows,

enter image description here

(click here for full size image)

My problem is client could not retain the session once we are responding to the client. But the same functionality could be achieved by the system that we have purchased from the vendor (we don’t have source code of this to analyse the internal coding structure). I hope something wrong with the way that we are responding to the client.

How can I overcome this problem?

We are using Java 1.4.2, Websphere application server

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
SLM
  • 839
  • 3
  • 14
  • 31

1 Answers1

6

There are many things which can make a session disappear. I'd suggest to track them and verify if anything went right. This is easier to do if you understand how sessions work.

  • Session has been timed out. This usually defaults to 30 minutes. This is confiugureable by <session-timeout> in web.xml where you can specify the timeout in minutes. You can implement a HttpSessionListener to track session creation and destroy using a logger.

  • Session has forcibly been invalidated. This happens when the code calls HttpSession#invalidate(). This is trackable with a HttpSessionListener as well.

  • Session cookie has been disappeared. Sessions are backed by cookies. If a session is been created, the server will add a Set-Cookie header with session ID. The client should send the same cookie back as Cookie header in all subsequent requests on the (context) path as specified in the Set-Cookie header. This is trackable in the HTTP traffic monitor ("Network" tab) of browser's builtin web developer toolset (press F12 in Chrome/Firefox23+/IE9+). Cookies are accessible for all webapps on the same cookie domain. Also, if ServletC2 runs on a different webapp context than ServletC1, then it won't use the same session. Further, if the "server" webapplication runs on the same domain, then it's in theory able to wipe out all cookies of the "client" webapplication.

  • The client doesn't support cookies. A well designed webapplication uses URL rewriting with jsessionid to track cookieless clients between requests on the same webapplication. But the second webapplication has to do the same when redirecting back to the first webapplication.

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Thanks for the explanation & I like the clarity of your answer. Can you elaborate more on the 3rd point which you have described. Is there a way of getting the sessionId of `servletC1` into `servletS1` & `Set-Cookie` with that id on the response of `servletS2`? – SLM Apr 01 '11 at 06:40
  • Isn't it a security vulnerability to rewrite the URLs with `jsessionid`? You expose the session ID to possible unaware user. Is there an additional security mechanism? – fnst Apr 24 '13 at 07:57
  • 1
    @fnst: It's only a vulrenability if the user shares the URL in public and the link is been used by others as long as user's session is still active. There's no additional security mechanism. You could create an "IP-lock" yourself with help of a servlet filter or perhaps a custom session manager. – BalusC Apr 24 '13 at 11:03