Adobe Flex + J2EE Security - Mismatched SessionID!

So get this.

I have a servlet called FileUploader. It takes a multipart/form-data request and proxies the file to S3. At the same time, it records some data in our database regarding the user, filename, and so forth. Simple enough.

I have a Flex 3 application that acts as a file chooser on the client side. It propogates a FileReference, which is then submitted to my FileUploader servlet via a URLRequest. Again, straight forward.

My Flex application lives in a JSP mapped to /upload. I have used declarative security to protect /upload for all HTTP methods. I have a servlet that sets a User object, containing attributes relating to the current user, to the session a after successful login, so that the User bean will be available to the FileUploader servlet.

Here's where it gets interesting...

I go to /upload and am redirected to the login page. I login and am redirected back to /upload. The JSP at /upload outputs some information from the User bean stored in the session (verifying that the bean is set correctly) as well as the JSESSIONID and the Flex application. Great so far. I use the Flex app to choose a file, which is then submitted to the FileUploader servlet. The FileUploader servlet gets the HttpSession from the request and logs the JSESSIONID. Check it the result:

JSESSIONID from the JSP: f8e64a4e62840010b6067470a346
JSESSIONID from the log: f8ec7389408a60103998c6bb75f0

WHAT!?!?! How did that happen? Is the Flex application identifying itself to my server as a different user than the browser? How can this be? The Flex documentation states that flex applications will use the underlying browser state when interacting with J2EE declarative security.

WTF Adobe? Am I surprised that it is not working according to the documentation? Not in the least.

Whenever development is going well, and especially when ahead of schedule, some Adobe product will ruin the fun. Don't believe it? Google for the Flash External Interface bug where subclass field values will "float" up to their superclass if the superclass and subclass both have a field of the same name... drove me crazy last fall...