2 Replies Latest reply on Aug 11, 2006 11:53 AM by Bill White

    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?

        • 1. Re: Flex Data Service Destinations and ClientId
          seth_hodgson Level 1
          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.

          • 2. Re: Flex Data Service Destinations and ClientId
            Bill White Level 1
            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!