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
FileUploaderservlet via a
URLRequest. Again, straight forward.
My Flex application lives in a JSP mapped to
/upload. I have used declarative security to protect
/uploadfor all HTTP methods. I have a servlet that sets a
Userobject, containing attributes relating to the current user, to the session a after successful login, so that the
Userbean will be available to the
Here's where it gets interesting...
I go to
/uploadand am redirected to the login page. I login and am redirected back to
/upload. The JSP at
/uploadoutputs some information from the
Userbean stored in the session (verifying that the bean is set correctly) as well as the
JSESSIONIDand the Flex application. Great so far. I use the Flex app to choose a file, which is then submitted to the
FileUploaderservlet gets the
HttpSessionfrom the request and logs the
JSESSIONID. Check it the result:
JSESSIONIDfrom the JSP:
JSESSIONIDfrom the log:
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...