Does Flash Player transmit session cookies automatically?_问答_开发者

There's no access to the HTTP cookies from within a Flash movie, but I now have repeatedly read that Flash Player is supposed to take care of session cookies automatically. I could, however, not find any documentation about this, and it sure didn't work with m开发者_如何学Cy Flex client running against a Struts backend using the default JSESSIONID cookie.

So, does Flash Player handle session cookies or doesn't it, and if it does, how do I set it up?

The HTTP requests from Flash are sent through the browser - so yeah, the cookies are transmitted automatically. In fact, I am currently doing a site that handles logging-in (and hence setting the session cookie) in an HTML page and then forwards user to a Flash only page (). The flash page is sending a lot of requests to the server using URLLoader & URLRequest and I am able to verify the session cookie for each of those.

That said, you can access HTTP cookies from Flash using ExternalInterface.call(). Make sure allowScriptAccess in the SWF embedding code is set to appropriate value.

var cookies:String = ExternalInterface.call("function()
    {
        return document.cookie;
    }()");

Update: I haven't tried that (login in flash), but you might be right - Flash might be ignoring the Set-Cookie (or all) response headers. And unfortunately Flash does not let us access response headers either. But since it is possible to access the response headers in an AJAX response (using xhr.getResponseHeader) you can use ExternalInterface and outsource the login part to AJAX. Grab the headers in the AJAX response and set the cookie using javascript (according to this SO thread, browser will do that automatically). Once set, subsequent requests sent from flash would include the session cookie in them.

Use the ExternalInterface.addCallback method to register a flash method to be callable from javascript.

Flash Player usually does its networking through the browser, in which case setting and getting cookies is entirely handled by the browser.

If a site sends Set-Cookie, that should work.

You can't access response headers from within Flash content, just as you can't access them from JavaScript; there are fundamental security reasons why this is so. However, it is possible that someday Flash Player might allow you to read cookies through a cookie API, just as JavaScript does. In the meantime, ExternalInterface will let you call over to JS to read cookies.

There is one case where Flash Player does not send cookies, or may even send the wrong cookies. That is when you are using FileReference.upload(). This is a known Flash Player bug, although a very difficult one for Adobe to solve, because of NPAPI dependencies.

BTW, JSESSIONID is considered insecure at this point. It is vulnerable to CSRF attacks because the browser will blindly send it, no matter whose document is making the request. Most modern login systems use a hidden form field or other means of keeping the login nonce accessible only to pages from within your domain.

Wish I could tell you why your particular app isn't sending cookies. Have you tried comparing it against an all-HTML version? Have you spied on both network streams with a packet sniffer?

the question was asked 10 years ago, but I have got something to say in this regard for future readers.

The Flash Player does not transmit the default JSESSIONID in the request and cannot do it until you have set SameSite=None in the JSESSIONID cookie.

I have faced the problem where the JSESSIONID cookie is dropped in the request and I have discovered that it is because modern browsers (chrome > 80) does not allow the Flash Player to access the JSESSIONID cookie it the cookie does not have SameSite=None and Secure flash.

Please, read the announcement from Adobe here More to read about the new cookie policy:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
https://medium.com/adobetech/adobe-experience-cloud-cookie-updates-for-google-chrome-19ad67cf1598
https://digiday.com/media/what-is-chrome-samesite/

I'm sure this thread is dead by now, but I was recently faced a similar issue using ASP.NET and the FileUpload, and found a work-around based on some of the work here.

I built a component that dynamically writes Flex objects to the page so they can be used in UpdatePanels. Message me if you want they code. To solve the above problem in pages where authentication cookies will need to be sent by URLRequest, I add the values in as flashVars.

This code only works in my object, but you get the idea

Dictionary<string, string> flashVars = new Dictionary<string, string>();     
flashVars.Add("auth", Request.Cookies["LOOKINGGLASSFORMSAUTH"].Value);
flashVars.Add("sess", Request.Cookies["ASP.NET_SessionId"].Value);
myFlexObject.SetFlashVars(flashVars);

Then in the Flex Object, check for the params

if (Application.application.parameters.sess != null)
    sendVars.sess= Application.application.parameters.sess;
if (Application.application.parameters.auth != null)
    sendVars.au= Application.application.parameters.auth;

request.data = sendVars;
request.url = url;
request.method = URLRequestMethod.POST;

Finally stuff the cookies in on global.asax BeginRequest

if (Request.RequestType=="POST" && Request.Path.EndsWith("upload.aspx"))
{
    try
    {
        string session_param_name = "sess";
        string session_cookie_name = "ASP.NET_SESSIONID";
        string session_value = Request.Form[session_param_name]; // ?? Request.QueryString[session_param_name];
        if (session_value != null) { UpdateCookie(session_cookie_name, session_value); }
    }
    catch (Exception) { }

    try
    {
        string auth_param_name = "au";
        string auth_cookie_name = FormsAuthentication.FormsCookieName;
        string auth_value = Request.Form[auth_param_name];// ?? Request.QueryString[auth_param_name];

        if (auth_value != null) { UpdateCookie(auth_cookie_name, auth_value); }
    }
    catch (Exception) { }   

}

Hope this help someone avoid the 6 hours I just spent addressing this. Adobe has closed the issue as unresolvable, so this was my last resort.