Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I need to prevent the situation where either
1. Two different JSESSIONID’s exist for the same user account or,
2. Two tabs of a single browser reference the same JSESSIONID.
Any suggestions? If an existing session is detected, the user can either:
a) Quit the second attempt
b) Kill the existing session (an assassin!) and start a new session.
The preference is for a sever-side solution. That is, I don’t want to depend on user’s turning cookies off which forces the JSESSIONID into the URL.
Part 1 could be done using a singleton pattern that checks current sessionid for the user against a map of user-SID.
Part 2, which could be understood in transactional webapps where you need to ensure that the user reads the correct info (instead of having a one tab with old values and one tab with newer values- scenario)… it could use the same sessionid map, injecting it in the dom and validate it using javascript.
EDIT. Part 2 validation could be done better in a filter against the map of client-sessionid. And a correct definition of the object guarantees that a true unique singleton instance exists.