This content has been marked as final. Show 2 replies
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.
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!