Flex Data Service Destinations and ClientId

[Bill_White]

I'm trying to figure out the relationship between the
FlexSession created when a user starts a Flex FDS-based application
and the clientId value in the messages being exchanged. Based on
what I'm seeing, I've found that a user will have the same
FlexSession Id value, but a different clientId value in the
messages being exchanged for each FDS destination.



The reason I'm interested is because I'm trying to manually
perform Acegi authentication and when the user logs in with my
login remote server, I set the Authentication token in the
ThreadLoad SecurityContextHolder. However, when I try to use other
destinations to retrieve data, the token is not present in the
SecurityContextHolder and I'm wondering if this is because Flex
considers the request to be from a different client because the
destination is different than the one I used to login, even though
the same FlexSession is being used by all destinations. Does anyone
know if this is the case?



Thanks

[seth_hodgson]

Hi Bill,



FlexSessions correspond to the connections between the Flash
client and the server.

The clientId in messages sent to the server correspond to a
Consumer or Producer instance on the client (or higher level
components like RemoteObject or DataService that use these base
messaging components internally).



If we imagine an app that creates two Consumer instances that
subscribe to destinations on the server and the destinations are
configured for RTMP access you'll have:

1. A single RTMP connection from the client to the server
with an associated FlexSession on the server. This session's
lifecycle is tied to the lifecycle of the RTMP socket connection.
If you set credentials on the client and authenticate, this session
will store the auth'ed principal.

2. Two Consumer instances that recieve pushed messages from
the server over the single RTMP connection. These consumer
instances will each have a unique clientId. This is what allows us
to muliplex the message traffic for multiple messaging components
on the client over a single connection to the server.



So the clientId in messages isn't a global identifier for the
Flash app running in the browser. Different destinations are
accessed by different DataService/RPC/Consumer/Producer instances
on the client and each of these will have a unique clientId. I
haven't worked with Acegi so I'm not familiar with its
SecurityContextHolder, but FDS's security is based on an
authenticated Principle existing in the FlexSession.



One final point to be aware of is that an RTMP connection to
the server and HTTP access do not share a single FlexSession.
Because the app server controls the lifecycle and timeout of Http
sessions, unlike RTMP connections which are a long-lived pinned
open socket connections with lifecycles controlled by the client
and FDS, these channels have separate sessions on the server. In
the Http case, we simply wrap the existing HttpSession maintained
by the app server. In the RTMP case the session lives and dies
along with its underlying socket connection.



Best,

Seth

[Bill_White]

Wow! Thanks for the excellent answer! That information really
helps me out. I figured out that by setting the
SecurityContextHolder strategy to MODE_GLOBAL, the threadlocal
storage of the authentication token works in Flex Data Services. I
guess that the default mode does not put it into every place
necessary for use in FDS.



I've got another question about the HTTP, RTMP and AMF
relationships, but I think it is best if I post that in a new topic
so as not to bury it from others. I hope you'll be able to answer
that one as well! Thanks again!