The creds passed to ChannelSet.login() are cached in client memory in Base64 encoded format and are cleared by a ChannelSet.logout() call. This allows channel hunting/fallback to be seemless at initial connect time as well as during reconnect following a temporary network failure or the remote clustered server that you're currently connected to failing.
There are legacy setCredentials() and logout() methods on RemoteObject, etc. but those should be avoided because authentication is actually scoped to your connection to the server (in the case of an HTTP server session, the scope is the entire browser process - including all tabs/windows/etc.), not to a specific RemoteObject instance. Remember to always use a secure channel+endpoint when your client is authenticating to the server, to keep the encoded creds safe over the network. To dodge the timeout entirely, issuing a no-op request from the client to the server on a Timer interval shorter than your server session timeout will keep the server session alive and logged in. Best, Seth From: [email protected] [mailto:[email protected]] On Behalf Of rydellfinn Sent: Tuesday, January 06, 2009 2:21 PM To: [email protected] Subject: [flexcoders] Re: BlazeDS - Best practice for determining if server session is invalid. 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!
