Seth - Thanks for the detail - I just noticed your answer on this one over break.
Setting login-after-disconnect to true does sound appealing. I'm was curious, where are the credentials stored to allow the reconnection? In the server session or on the client? Also - I did successfully get the "Client.Authentication" error when I hit a service after the session timed out. That helps. I was interested in catching the timeout before it occurs so I can warn the user before the timeout occurs. To implement this, I was thinking of setting a client-side timer that would pop up a warning message on an interval that is smaller than the server timeout length. Is there a better way? Thanks again for your help! --- In [email protected], Seth Hodgson <shodg...@...> wrote: > > Hi, > > In your services-config.xml file, within the <properties> for the channel/endpoint you app is using to issue remoting calls to the server, try turning on the following config option: > > <!-- Optional. Default is false. Setting this flag to true will cause clients > to automatically attempt to re-authenticate themselves with the server when > they send a message that fails because credentials have been reset due to server > session timeout. The failed message will be resent after re-authentication making the > session timeout transparent to the client with respect to authentication. > --> > <login-after-disconnect>true</login-after-disconnect> > > This is also exposed as the 'loginAfterDisconnect' property on Channel, if you're building your channels and ChannelSet directly in ActionScript. > > It should handle this case seamlessly, removing the need to re-prompt the user with a login dialog. > If you really want to reprompt the user, in your fault handler for your RemoteObject calls, you could watch for faults with an underlying ErrorMessage with a faultCode of "Client.Authentication" and use that to trigger transition back to your login view. > > The reason that the authenticated property doesn't change on the client is that there's no way guaranteed way for the server to notify the client when the session times out. So, it's not until you send your next request to the server that we discover that. > > Best, > Seth > > From: [email protected] [mailto:[email protected]] On Behalf Of rydellfinn > Sent: Wednesday, November 05, 2008 6:15 PM > To: [email protected] > Subject: [flexcoders] BlazeDS - Best practice for determining if server session is invalid. > > Currently I am running BlazeDS on Tomcat, and I have a flex client > that is authenticating against a set of Remote Objects using > channelset.login(). > > As expected, if I walk away from the client for 30 minutes, the Tomcat > server invalidates the session, which of course effectively logs out > the client. > > What I would like to happen is when the server invalidates the > session, the client is returned to the login page. I can think of > different ways to accomplish this, but I was wondering if there is an > established pattern for this? > > I tried creating a timer on the client to check if the authenticated > property on the channelset was false. But I noticed that the > authenticated property never changed, even after the session invalidated. > > I'm tempted to do the same thing on the server, but instead check to > see if the session is valid, and throw an error if not. > > But I thought I'd check here first! > > Thanks in advance! >
