Oh, a GWT app. My suggestion would be to turn up logging on both sides. I'm assuming that InvocationException has a cause. You set `org.apache.shiro` log level to DEBUG or TRACE, and you should be able to get more info.
On Tue, May 25, 2021 at 3:04 PM alina.frey <[email protected]> wrote: > I tried to pinpoint at what version of Shiro my application starts to lose > session. > So, nothing is changed in my application other than the shiro library. > Discovered that the session loss happens starting with Shiro 1.3.2. > o shiro-all.1.2.3.jar: No session loss. Login works. > - Current version > o shiro-all.1.2.6.jar: No session loss. Login works. > o shiro-all.1.3.2.jar: Session loss!! > Need to figure out what changed between version 1.2.6. and 1.3.2, > and > change settings. > Maybe shiro.ini needs to change, but I don't know what to change. > > Narrowing down to where the application actually crashes: > o In UserLoginWindow.loginAttempt - Client side > > MainEntryPoint.loginService.tryLogin(username, > password, callBack) - > Client side > > LoginServiceImpl.tryLogin(username, > password) - Server side > > The user is authenticated (Log > messages from server side are > visible). > > the callBack is onSuccess - Client side > o Inside onSuccess: > > The callBack returns the UserLoginBean, which is > not null and all > properties (username, password, etc.) have assigned value, with the > exception of sToken > > there are three cases: > 1. userLoginBean = null - this is the > case where Access is denied, and > it prompts the user to login again > 2. userLoginBean.getSalt == null - > this is the case where the user needs > to change password > 3. All other cases > > In our case we are passing the first two steps, > landing in the third > case. > > In the third case, it calls a few functions, > from the Client side to > the Server side, but it looks like the application never reaches the server > side. > > The very first function that is called from the > Client side to the > Server side returns onFailure in its callBack!! - This is where the > sessionID that is displayed in the web browser changes. > > Every other function that is called after this, > from the Client side to > the Server side, returns onFailure. > > So, in conclusion, it looks like the application crashes right after the > user is logged in with Shiro 1.3.2, and ANY call is made from the Client > side to the Server side. > > To answer the follow-ups: > > 1. What is the error message that displays on your login page? > The message that is displayed is a general message for the cases when the > exception caught is an instance of > com.google.gwt.user.client.rpc.InvocationException. The actual text > displayed is "The session has expired. The user needs to relogin." But it's > not relevant, as it doesn't explain why it's an InvocationException :). > > 2. What else changed in your application? > Nothing other than changing Shiro from 1.2.3 to 1.2.6 to 1.3.2. Shiro 1.3.2 > breaks the application. > > 3. Do you have a minimal repro example you can share on GitHub (or > similar)? > I don not have one, and I don't think I can share much :). > > 4. Were you able to look at the cookies in your browser? > Yes, I can see the sessionID in the browser. For Shiro 1.2.3 and 1.2.6, the > sessionID stays the same and the application is able to load after > successful login. > When Shiro is changed to 1.3.2, the sessionID changes, right after the user > is authenticated on the server side. On the Client side under callBack > onSuccess, the very first function that is called is a call to Server side. > That function returns onFailure, like every other function after that, > which > are calls to the Server side. > > > > -- > Sent from: http://shiro-user.582556.n2.nabble.com/ >
