Question

Long story short, I have to inform a 3rd party Web Service that follows a weird business logic, when a user logs in and out, in my J2ee Portal. So I'm following her httpSession start/end/timeout

But it's possible for a user to create multiple httpSessions, e.g by opening multiple browsers. In this case, when an httpSession ends, either by timing out or from a log-out, if I inform the 3rd party service, it will invalidate some Objects, and cause problems to the rest of the living httpSessions.

I can think of many ways to deal with that, like :

  1. Preventing multiple httpSessions per user, extending the login Process.
  2. Counting (stack-logic) the user's httpSessions, and inform the 3rd party Service, only when the last HttpSession Ends and the 1st hhtpSession Starts
  3. Just provide the user with an error message that she's not supposed to use multiple browsers, and force to repeat login.
  4. Tell the 3rd party Developers to deal with that on their side. After all I shouldn't be burdened from their awkward business logic.

But I'm getting the feeling that I'm re-inventing the wheel here, and I'm missing an obviously better and widely adopted practice

What do you think would be the most convenient way to handle multiple simultaneous httpSessions

Was it helpful?

Solution

Do you want to fix this on the frontend (e.g. restrict the users to login twice) or on the backend (e.g. discouple your backend implementation & cache from HTTP sessions.

With users getting more and more mobile, I feel that you should rather go and fix the backend problem and adapt your architecture accordingly.

I know that this doesn't exactly answer your questions, but I feel this is quite a critical aspect of a software architecture. In 95% of apps where I've seen this demand, it was not for business reasons (where this actually makes sense) but rather as a technical workaround.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top