I want to clarify what I have observed about the Flash Cookie bug.
The Flash Player Plugin for FireFox, Opera and Safari (and probably other non-IE based browsers) has a bug which sends persistent cookies from IE to the upload URL instead of the cookies from the browser. Session only cookies from IE are not sent.
When Flash initializes in the browser its own empty "cookie space" is created. It loads persistent cookies from IE (which you can see in %USERPROFILE%\cookies). In-memory (session) cookies are not loaded.
The cookies from the browser are not loaded in to Flash's cookie space.
Any session cookies created by the upload script are maintained in-memory in Flash's cookies space. New persistant cookies are created on disk (which you can see in %USERPROFILE%\cookies) and will immediately appear in IE. Cookies created in the Flash cookie space will not appear in any of the browser's "view cookie" tools.
All Flash Movies share the same per browser cookie space which is maintained until the browser is closed (i.e., multiple tabs in FireFox will share the same Flash cookie space but FireFox and Safari maintain separate Flash cookie spaces).
I've carefully tested this issue in FireFox 3 and IE 7 on Windows XP Pro with Flash Player 9.0.115. I also did some basic testing in Opera 9.24 and the Safari Beta for Windows. I plan to create a new demo which will demonstrate my findings.
I have not tested this issue on OS X or in Linux.
March 5, 2008 - 10:49pm
I've created a Cookie Bug demo which you can see at http://demo.swfupload.org/cookiebugdemo/. Please follow the instructions before saying that it doesn't do anything.
Remember that this is not a bug in SWFUpload but in the Flash Player.
This might be considered a proof of concept for a Flash security issue or as a tricky way to communicate between IE and another browser using Flash.
March 6, 2008 - 8:17am
Just wondering:
What are the effects of this bug to watch out for?
How does it limit us with 2.10?
Should we be working around it in some way?
Regards,
LTG
ecards & greeting cards
March 6, 2008 - 12:14pm
1) Any cookies from a non-IE browser (ie, authentication, login, etc) will not be sent with the file upload. Rather the cookies from IE will be sent. So, no cookies or the wrong cookies will be sent. In most cases this means sessions and cookie based authentication are lost when making an upload.
2) Cookies set by the upload script do get set, but only for Flash. The browser will not see them.
3) This bug affects Flash 8 and Flash 9 and all versions of SWFUpload
4) You cannot rely on cookies when using SWFUpload (or any Flash based upload tool). You must send the data you need from the cookies in another way. There are several threads regarding this issue in the forum and many of the demos show workarounds for restoring PHP sessions and some sample files show how to restore the cookies so Session and Authentication are restored in ASP.Net.
5) This could be considered a security issue but probably not severe enough to actually compromise any data. The cookies created in IE by Flash still have all the rules and restricts associated with cookies in any browser.
March 6, 2008 - 2:35pm
for helping to understand this one--
Seems crazy that Adobe isn't all over this.
March 27, 2008 - 9:21am
At last I found a solution that enables the use of SWFUpload with Drupal (and have Mac users be able to make it to the party), while leaving the core code intact.
Check it out (if you need more details I will provide):
http://blog.ascaniocolonna.com/?p=23
April 17, 2008 - 3:36am
Ive just made a post on the CodeIgniter forums about this issue as well..
http://codeigniter.com/forums/viewthread/77044/
February 2, 2009 - 12:19pm
I'm having issues that I believe relate to this (error 403 within swfuploader).
I'm developing a module that uses SWFUploader and a drupal menu callback as the upload_url within this function I then do all of my functionality to upload the files to Amazon S3. I keep getting this:
SWF DEBUG: Event: fileDialogStart : Browsing files. Multi Select. Allowed file types: *.*SWF DEBUG: Select Handler: Received the files selected from the dialog. Processing the file list...
SWF DEBUG: Event: fileQueued : File ID: SWFUpload_0_0
SWF DEBUG: Event: fileDialogComplete : Finished processing selected files. Files selected: 1. Files Queued: 1
SWF DEBUG: StartUpload: First file in queue
SWF DEBUG: Event: uploadStart : File ID: SWFUpload_0_0
SWF DEBUG: Global Post Item: PHPSESSID=gof8oipur7qo3n2drutg2pco22
SWF DEBUG: ReturnUploadStart(): File accepted by startUpload event and readied for upload. Starting upload to /photoshoot_project/upload/handler/1 for File ID: SWFUpload_0_0
SWF DEBUG: Event: uploadProgress (OPEN): File ID: SWFUpload_0_0
SWF DEBUG: Event: uploadProgress: File ID: SWFUpload_0_0. Bytes: 13732. Total: 13732
SWF DEBUG: Event: uploadError: HTTP ERROR : File ID: SWFUpload_0_0. HTTP Status: 403.
SWF DEBUG: Event: uploadComplete : Upload cycle complete.
Error Code: HTTP Error, File name: image.jpg, Message: 403
I think your fix will do the trick, but how do I set and send the session name?
February 2, 2009 - 12:42pm
When working around the cookie bug you have to modify the server side script to look for the alternate cookie value (not passed as a cookie but as a post parameter) and then restore the cookies or session manually.
You might have to do this in Drupal. Maybe here someone knows hows.
February 2, 2009 - 2:17pm
Is this what is needed to restore it?
if(!isset($_COOKIE[$_POST['PHPSESSNAME']])) {
$_COOKIE[$_POST['PHPSESSNAME']] = $_POST['PHPSESSID'];
}
if (isset($_POST["PHPSESSID"])) {
session_id($_POST["PHPSESSID"]);
}
session_start();
Or is there something simple that I'm missing?
February 2, 2009 - 3:49pm
Ok,
So I noticed that I was checking the drupal permissions before the cookie data could be reset in the function so I removed the menu permissions and put them within the function itself.
The problem that I'm having now is that the current session is lost for the logged in user.
Messed up work flow is:
User logs in and goes to upload page, uploads as many files as they want, then tries to navigate to another 'restricted' area and it says they don't have permission. (in effect they have been logged off)
What can I Do?
September 23, 2009 - 3:46am
Upon testing, .htaccess might solve the problem. It removes authentication for that certain file and prevents firefox from crashing.
I create .htaccess file within the same folder with my_uploader_script.php Below is my .htaccess
<Files "my_uploader_script.php">
Satisfy Any
</Files>
http://topeinthehouse.blogspot.com/2009/09/solution-for-flash-cookie-bug...
December 3, 2009 - 7:33pm
If anyone want to encourage Adobe to fix this bug, here are the bug-tracker links for this issue:
https://bugs.adobe.com/jira/browse/FP-1044
https://bugs.adobe.com/jira/browse/FP-419
https://bugs.adobe.com/jira/browse/FP-201
https://bugs.adobe.com/jira/browse/FP-78
Unfortunately you have to create an account to view the issues, but there they are anyway.
February 5, 2010 - 2:36am
It has enabled me to get a handle on an issue we were seeing in our network with users access in terminal servers (it was in IE). Adobe have not responded at all on the essential question of where cookies are stored. Your post enabled me to set permissions properly.
Don't be surprised Adobe haven't done anything, they are worse than any other company I deal with in terms of support - worse than MS, worse than Xerox, Intel......
thanks again