How do I do sessions with a Flash client?

2019-03-06 14:49发布

问题:

Since the Flash Player (or, more exactly, the URLLoader class) will not let you read HTTP response headers or cookies set by the server, and if you get hold of a session cookie through some workaround like reaching out to the browser and run JS, you can't send it to the server, because, among others, the Cookie header will be blocked.

Now I'm building a Flex client against an HTTP API for my server product. I control both sides, so I can get get around the above limitations, now I'm wondering how. I see the following options:

  1. include the session token in the HTTP payload
  2. include the token in the URL
  3. build my own HTTP client (... with blackjack, and hookers ...) in AS, using the Socket class

I don't like (1), because I'm reimplementing functionality in my protocol that is already built into Struts, which I'm using to implement the server side. I then have to ensure that either both behave the same way, or turn off the usual way of session management and force other clients to use my protocol where they could just have the browser deal with it.

I don't like (2), because I understand that there are security concerns with this, although I'm not too sure which

I don't like (3), because it's 2010 and tons of HTTP clients have been written by smarter people than me.

So, are there other opportunities? Which of my "don't like"s do you reckon least severe? Are there ways to mitigate the problems I listed? For example, how insecure are session tokens in URLs really?

回答1:

How about using the FlashVars parameter? It's designed explicitly to pass simple data into a Flash app, and it's trivial to embed the session token into the tag when the page is generated server-side. PHP-wise, it'd be something like

<embed href="movie.swf" flashvars="sessionID=<?= session_id(); ?>">blah blah blah</embed>

This way there's no session data in the movie's url that could leak via referers, and the data's already "there" so the app doesn't have to reach out and talk to the browser. And if someone's sniffing the source HTML page to get the data, they could have gotten the same information from the HTTP headers anyways.

There's more details here in the Adobe docs.



回答2:

Some of your post may have eluded me, but do you know about Shared Objects:

"The SharedObject class is used to read and store limited amounts of data on a user's computer or on a server. Shared objects offer real-time data sharing between multiple client SWF files and objects that are persistent on the local computer or remote server. Local shared objects are similar to browser cookies and remote shared objects are similar to real-time data transfer devices.