BlazeDS - Best practice for determining if server session is invalid.

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

BlazeDS - Best practice for determining if server session is invalid.

rydellfinn
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!

Reply | Threaded
Open this post in threaded view
|

RE: BlazeDS - Best practice for determining if server session is invalid.

Seth Hodgson
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: [hidden email] [mailto:[hidden email]] On Behalf Of rydellfinn
Sent: Wednesday, November 05, 2008 6:15 PM
To: [hidden email]
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!

Reply | Threaded
Open this post in threaded view
|

Re: BlazeDS - Best practice for determining if server session is invalid.

fotis.chatzinikos
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 <[hidden email]> 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: [hidden email] <flexcoders%40yahoogroups.com> [mailto:
> [hidden email] <flexcoders%40yahoogroups.com>] On Behalf Of
> rydellfinn
> Sent: Wednesday, November 05, 2008 6:15 PM
> To: [hidden email] <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
[hidden email],
Reply | Threaded
Open this post in threaded view
|

RE: BlazeDS - Best practice for determining if server session is invalid.

Seth Hodgson
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: [hidden email] [mailto:[hidden email]] On Behalf Of Fotis Chatzinikos
Sent: Tuesday, November 25, 2008 3:46 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of rydellfinn
Sent: Wednesday, November 05, 2008 6:15 PM
To: [hidden email]
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
[hidden email],

Reply | Threaded
Open this post in threaded view
|

Re: BlazeDS - Best practice for determining if server session is invalid.

fotis.chatzinikos
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 <[hidden email]> 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: [hidden email] <flexcoders%40yahoogroups.com> [mailto:
> [hidden email] <flexcoders%40yahoogroups.com>] On Behalf Of
> Fotis Chatzinikos
> Sent: Tuesday, November 25, 2008 3:46 PM
> To: [hidden email] <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 <[hidden email]<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: [hidden email] <flexcoders%40yahoogroups.com> [mailto:
> [hidden email] <flexcoders%40yahoogroups.com>] On Behalf Of
> rydellfinn
> Sent: Wednesday, November 05, 2008 6:15 PM
> To: [hidden email] <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
> [hidden email] <Fotis.Chatzinikos%40gmail.com>,
>
>  
>



--
Fotis Chatzinikos, Ph.D.
Founder,
Phinnovation
[hidden email],
Reply | Threaded
Open this post in threaded view
|

Re: BlazeDS - Best practice for determining if server session is invalid.

fotis.chatzinikos
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 <
[hidden email]> 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 <[hidden email]> 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: [hidden email] <flexcoders%40yahoogroups.com> [mailto:
>> [hidden email] <flexcoders%40yahoogroups.com>] On Behalf Of
>> Fotis Chatzinikos
>> Sent: Tuesday, November 25, 2008 3:46 PM
>> To: [hidden email] <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 <[hidden email]<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: [hidden email] <flexcoders%40yahoogroups.com> [mailto:
>> [hidden email] <flexcoders%40yahoogroups.com>] On Behalf Of
>> rydellfinn
>> Sent: Wednesday, November 05, 2008 6:15 PM
>> To: [hidden email] <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
>> [hidden email] <Fotis.Chatzinikos%40gmail.com>,
>>
>>  
>>
>
>
>
> --
> Fotis Chatzinikos, Ph.D.
> Founder,
> Phinnovation
> [hidden email],
>



--
Fotis Chatzinikos, Ph.D.
Founder,
Phinnovation
[hidden email],
Reply | Threaded
Open this post in threaded view
|

RE: BlazeDS - Best practice for determining if server session is invalid.

Seth Hodgson
Hi Fotis,

The AMFChannel (and its Secure variant) define a 'hidden' method that you could override to get access to the jsessionid value that is returned to the client at connect time for your current server session.

Here's the method signature: override public function AppendToGatewayUrl(value:String):void

You'd want to override in your own custom subclass of AMFChannel, invoke super, and then parse and store that value somewhere for use in your file upload handler.

The method name dates back to Flex 1, and will likely remain undocumented, but go ahead and log an ECR to have the value exposed as a bindable public property on the channel: https://bugs.adobe.com/blazeds/

Thanks,
Seth

From: [hidden email] [mailto:[hidden email]] On Behalf Of Fotis Chatzinikos
Sent: Thursday, November 27, 2008 5:11 AM
To: [hidden email]
Subject: Re: [flexcoders] BlazeDS - Best practice for determining if server session is invalid.

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 <[hidden email]> 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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Fotis Chatzinikos
Sent: Tuesday, November 25, 2008 3:46 PM
To: [hidden email]
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of rydellfinn
Sent: Wednesday, November 05, 2008 6:15 PM
To: [hidden email]
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!
--
Reply | Threaded
Open this post in threaded view
|

Re: BlazeDS - Best practice for determining if server session is invalid.

rydellfinn
In reply to this post by Seth Hodgson
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 [hidden email], Seth Hodgson <shodgson@...> 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: [hidden email] [mailto:[hidden email]]
On Behalf Of rydellfinn
> Sent: Wednesday, November 05, 2008 6:15 PM
> To: [hidden email]
> 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!
>


Reply | Threaded
Open this post in threaded view
|

Re: BlazeDS - Best practice for determining if server session is invalid.

rydellfinn
In reply to this post by Seth Hodgson
Hi -

Sorry, I know this was a while ago, but this is a link to creating a
LoginCommand that uses Spring Security(Acegi)....

http://code.google.com/p/igenko/source/browse/trunk//blazeds-spring/src/main/java/flex/messaging/security/AcegiLoginCommand.java?r=267



--- In [hidden email], Seth Hodgson <shodgson@...> 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: [hidden email] [mailto:[hidden email]]
On Behalf Of Fotis Chatzinikos
> Sent: Tuesday, November 25, 2008 3:46 PM
> To: [hidden email]
> 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 <shodgson@...> 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: [hidden email] [mailto:[hidden email]]
On Behalf Of rydellfinn
> Sent: Wednesday, November 05, 2008 6:15 PM
> To: [hidden email]
> 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
> Fotis.Chatzinikos@...,
>


Reply | Threaded
Open this post in threaded view
|

RE: Re: BlazeDS - Best practice for determining if server session is invalid.

Seth Hodgson
In reply to this post by rydellfinn
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: [hidden email] [mailto:[hidden email]] On Behalf Of rydellfinn
Sent: Tuesday, January 06, 2009 2:21 PM
To: [hidden email]
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!