I’m supporting some project, built using ADF (using JDeveloper 11.1.2.2.0) and deployed to Tomcat 7.0.28.
There was an issue with JSessionID:
IT should be different before logging-in and after it. To solve this, in my method validate() (that is executed when user submits login form) I do the following:
ExternalContext ec = FacesContext.getCurrentInstance().getExternalContext();
HttpSession session = (HttpSession)ec.getSession(false);
session.invalidate();
session = (HttpSession)ec.getSession(true);
//setting some special session attributes
ec.redirect("nextPage");
When I arrive to nextPage I can get session with special attributes set above and go further. Everything works good when I log-in from Firefox or Chrome.
But when I log-in using IE 8.0 and get redirected to nextPage, my code gets session without those special attributes and throws me back to login page.
Using Wireshark I’ve realized that when Firefox logs-in it sends POST request with user input (username/password), receives answer with new JSessionID in SetCookie parameter, sends another request with Adf-Window-id and receives answer, after that it is redirected to nextPage.
But for IE flow is different: on log-in IE sends two POST request in a row (first with user input, second with Adf-Window-id) and after that receives two answers, each with different JSessionID. It stores the last one and gets redirected to nextPage. Obviously, the last JSessionID belongs not to the session where I’ve set my special attributes.
I’ve already spent few days trying to solve this problem by digging configs and Google, with no success. All I can see – IE sometimes can log-in as expected (in this case two answers mentioned above are received in reverse order), but it happens seldem.
Maybe you have faced same problem and solved it? Or maybe I’m doing/expecting something wrong?
I’ve solved the problem described by implementing my own servlet.
After successful logon the necessary session attributes are set and the session is not invalidated. Then, user gets redirected into context of my own servlet, which saves all session attributes, invalidates the session, creates new one and restores old attributes. After that, this servlet redirects user further, where he should get after logon. Of course, there are some tricks for security.