Seth, any ideas if there is a way to get the session id of the new session
when the automatic re-login happens?

Is there an event that is dispatched when this happens?

At the moment i get the jsession id via an rpc call in order to use it in
various places where it is needed, for example when images are uploaded to
the server...


On Wed, Nov 26, 2008 at 3:34 AM, Fotis Chatzinikos <
[EMAIL PROTECTED]> wrote:

> Hello Seth, I had not bumped across any of this so thanks! I will have a
> look and hopefully -NOT- let you know (ie it will work :-)
>
> Thanks again,
> Fotis
>
>
> On Wed, Nov 26, 2008 at 2:26 AM, Seth Hodgson <[EMAIL PROTECTED]> wrote:
>
>>   Hi Fotis,
>>
>> The client library caches credentials in order to support seamless
>> fallback through channels in your ChannelSet that preserves your desired
>> authenticated identity both at connect time, as well as for automatic
>> failover across peer servers in a cluster at any point after you've
>> initially connected.
>>
>> However, when you use a simple AMF channel, where we don't know your
>> session (connection) has timed out until a remoting call is made but fails
>> due to an auth constraint check, we didn't originally handle that scenario
>> seamlessly. Now we do, when you turn on the config flag I mentioned below,
>> and it applies to remoting calls, producer messages sends, DMS operations,
>> etc. (basically, any outbound message that fails in processing due to an
>> auth fault when you were previously successfully authenticated).
>>
>> In order for this to work though, you'd need to be logging in from within
>> the Flex app so that it has access to your creds.
>> We provide server-side LoginCommand impls for supported app servers that
>> plug into their various custom authentication layers and that's what Flex
>> login requests are processed by, but we don't ship an official
>> AcegiLoginCommand currently. I think folks in the community have implemented
>> that though, so try Googling for it, or perhaps someone else who's written
>> one will post a link?
>>
>> There's more detail here:
>> http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/help.html?content=services_security_2.html
>>
>> And here:
>> http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/help.html?content=services_security_5.html#348164
>>
>> Best,
>> Seth
>>
>> From: [email protected] <flexcoders%40yahoogroups.com> [mailto:
>> [email protected] <flexcoders%40yahoogroups.com>] On Behalf Of
>> Fotis Chatzinikos
>> Sent: Tuesday, November 25, 2008 3:46 PM
>> To: [email protected] <flexcoders%40yahoogroups.com>
>> Subject: Re: [flexcoders] BlazeDS - Best practice for determining if
>> server session is invalid.
>>
>>
>> Hi Seth,
>>
>> the following line looks quite promising:
>>
>> >>It should handle this case seamlessly, removing the need to re-prompt
>> the user with a login dialog.
>>
>> Can you elaborate a bit?
>>
>> How is that possible?
>>
>> In my case I use spring-acegi to login, prior to the flash component, but
>> if there is another way - ie via a flash login box and automatic
>> re-authentication i would love a pointer on how to do it...
>>
>> Thanks,
>> Fotis
>> On Tue, Nov 25, 2008 at 11:15 PM, Seth Hodgson <[EMAIL 
>> PROTECTED]<shodgson%40adobe.com>>
>> 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] <flexcoders%40yahoogroups.com> [mailto:
>> [email protected] <flexcoders%40yahoogroups.com>] On Behalf Of
>> rydellfinn
>> Sent: Wednesday, November 05, 2008 6:15 PM
>> To: [email protected] <flexcoders%40yahoogroups.com>
>> 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!
>>
>> --
>> Fotis Chatzinikos, Ph.D.
>> Founder,
>> Phinnovation
>> [EMAIL PROTECTED] <Fotis.Chatzinikos%40gmail.com>,
>>
>>  
>>
>
>
>
> --
> Fotis Chatzinikos, Ph.D.
> Founder,
> Phinnovation
> [EMAIL PROTECTED],
>



-- 
Fotis Chatzinikos, Ph.D.
Founder,
Phinnovation
[EMAIL PROTECTED],

Reply via email to