Flash
 Flash Professional

     

Hi!

I am trying to upload an image using FileReference. It works great on internet explorer but fails in Firefox 3 and Chrome. I don’t care about chrome but yes Firefox.

I guess this is not a code problem but maybe a browser related one.
Does anyone knows if there is some incompatibility between the flash player FileReference.upload and Firefox?


this is the code:

var file:FileReference = afile.file;
var request:URLRequest = new URLRequest(__actionURL);
request.method = URLRequestMethod.POST;
//variables to be sent on request
var uploaderReqVars:URLVariables = new URLVariables();
//adding the image that contains a reference to the album and
//the custom title or filename
uploaderReqVars.data = serializer.serializeToString(image);
uploaderReqVars.action = "uploadFile";
request.data = uploaderReqVars;
//adding the method that will be executed when data loaded.
file.addEventListener(Event.CANCEL, handleUploadCanceledByUser);
file.addEventListener(DataEvent.UPLOAD_COMPLETE_DATA, uploadFileDataComplete);
file.addEventListener(IOErrorEvent.IO_ERROR, uploadFileDataError);
file.addEventListener(HTTPStatusEvent.HTTP_STATUS, uploadFileServiceError);
file.addEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);
file.upload(request, "file"); 

any comment will be welcome!
thanks

Polaco.

  20 REPLIES
Polaco Author 
1  
Polaco

I will explain a bit the context of this issue:
I’m using this Flash movie as the frontend of an Image Gallery done with a JSR 168 portlet.
The portal which I’m sending the requests requires authentication.

The flash movie allows me to upload an image and also edit it’s title once uploaded.

I have been debugging the request sent by IE and Firefox with HTTPDebuggerPro.
There is some strange thing happening.

When I send a request from IE-flash the session cookie id sent on the request it’s always the same no matters if i’m sending a FileReference upload request or a request to change an image title.

When I send a request from Firefox-flash the session cookie id sent on the request it’s the always the same if I edit an image title but it’s different when an FileReference.upload request it’s send it seems like Firefox creates a new session/cookie for file Reference uploads.

I have also found this bug report:
http://bugs.adobe.com/jira/browse/FP-78
but no solution.

Does anybody knows something about this?

thanks in advance.

Polaco.

  • 06 June 2009 04:48 PM
    •  
Polaco Author 
2  
Polaco

I have found this article:
http://www.defusion.org.uk/archives/2008/04/21/uploading-files-and-images-with-flex-and-rails/
maybe provides some help. Haven’t tried it yet. Maybe on tuesday.

  • 06 June 2009 05:59 PM
    •  
Nutrox
3  
Nutrox

Depending on how much control over the server-side code you have, you could pass the session ID to the server when you upload the image, the server-side script could then use that session ID to initialise the correct session. Getting the session ID into Flash is easy enough to do (use flashvars, request the ID from the server, etc).

  • 07 June 2009 03:36 PM
    •  
Polaco Author 
4  
Polaco

Hi Si!

I have not much control of the session parameters handling since session validation it’s done by the portal and not by my portlet. So the portlet doesn’t ever get called when a fileupload is requested. frown

I have tried what my previous post proposes with no results.
I couldn’t managed to override the session cookie sent by Firefox, no matter if I add a cookie as a URLRequestParameter on the URLRequest object and sending it as a normal parameter on the url doesn’t work.

I guess this post has a better approach to solve the problem:
http://www.pavlasek.sk/devel/?p=10
but I haven’t tested yet.

thanks!

  • 07 June 2009 03:47 PM
    •  
Polaco Author 
5  
Polaco

The worst part of this is not that it doesn’t work but the inconsistencies that the flashplayer are showing. This kind of things adding the fact that it’s impossible to edit text in fullscreen mode and that if you open a filebrowser window the player will exit the fullscreen mode. Makes me worry about the robustness of Flash as an application development platform.
Since this is the first application I have done that has a bit complex user interaction (other than just displaying data) and all this unespected things has appeared I wonder what other “bugs” could show their heads on a bigger scenario.
Of course maybe lots of this things could be solved with a bit more support from Adobe.

  • 07 June 2009 04:38 PM
    •  
Nutrox
6  
Nutrox

This is just a thought but have to tried uploading the image to a local server script (such as PHP or ASP) and then forwarding the uploaded file to the portlet? So the process would be Flash > (file) > PHP > (file) > Portlet. Flash might not need to deal with sessions at all that way.

  • 07 June 2009 04:55 PM
    •  
Polaco Author 
7  
Polaco

Mmm… Yes maybe an external servlet out of the security bounds of the Portal could do the upload part. It doesn’t look sooo nice big grin.
But could work I guess it could be an alternative.
Personally I try to avoid such a things due to maintenance problems and in favor of a more packaged solution I mean with no external files deployed in other context or whatever.
We have done such a things in the past when the portal didn’t allowed to exchange data in binary mode, for instance generating pdf reports to the user.

thanks a lot for your help Si!

  • 07 June 2009 05:34 PM
    •  
Polaco Author 
8  
Polaco

Oh no! damn!

Now I am trying to upload it with URLLoader. A beautiful error is thrown:
It says:
—————————————

Connection to
[url]http://10.15.64.206:8001/portal/site/Corporative/template.PAGE/action.process/menuitem.a81cb426d8b63b0bba5039209d04f0a0/?javax.portlet.action=true&javax.portlet.tpst=8df6582726d101a4a86c3c63ec04f0a0_ws_BI&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken[/url]
halted - not permitted from
[url]http://10.15.64.206:8001/repository/Comun/ImageGallery/Swf/ImageGallery.swf[/url] 

—————————————
Which is quite unspected since HTTPService’s invocations that I make from this swf against the same url works.
Aren’t both going against the same domain “http://10.15.64.206:8001”?
Any ideas?

thanks in advance.

Polaco.

  • 09 June 2009 11:04 AM
    •  
Nutrox
9  
Nutrox

Have you tried it without the port numbers?

  • 09 June 2009 11:17 AM
    •  
Polaco Author 
10  
Polaco

But I’m using relative paths. I think that path showed in the message it’s the final path build by the URLLoader internally.
:S

  • 09 June 2009 11:22 AM
    •  
Polaco Author 
11  
Polaco

this is the relative URL that I’m passing to the URLRequest that is then passed to the urlLoader when load method is invoked.

/portal/site/Corporative/template.PAGE/action.process/menuitem.a81cb426d8b63b0bba5039209d04f0a0/?javax.portlet.action=true&javax.portlet.tpst=8df6582726d101a4a86c3c63ec04f0a0_ws_BI&javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken 

knocked-out

  • 09 June 2009 11:29 AM
    •  
Polaco Author 
12  
Polaco

mmm it seems that the error is happening due to another security policy, yet I don’t understand why it’s showing that trace. I will update as soon as I have some better understanding on what’s going on.

thanks a lot Si.

  • 09 June 2009 12:21 PM
    •  
Nutrox
13  
Nutrox

No need to thank me, I haven’t given you any help yet. bigsmile

I have tried to reproduce the error on my dev server but haven’t had any luck, it seems strange that relative paths should cause a security problem. I guess Flash could be reading the URI incorrectly… maybe the dots in the folder names are causing the problem?

  • 09 June 2009 12:43 PM
    •  
Polaco Author 
14  
Polaco

Hi Si, I feel a bit stupid now more than I regulary feel.d’oh!
The security sandbox problem was due to I was sending the upload on a FileReference complete event handler. So as the URLUploader needs a user interaction to begin the upload I had to split this in two parts. First the user selects the image to upload and this fires the Filereference.load method, when the filereference load is complete an upload button becomes available and clicking it fires the caingorm event which finally it’s delegate makes the call to URLUploader.

So the good news is that now works in Firefox and IE. This is a good sign that could work under HTTPS too, thing that I will test in a few hours.
The bad news is that it requires FlashPlayer10.

  • 09 June 2009 01:07 PM
    •  
Nutrox
15  
Nutrox

No need to feel stupid. Yesterday I spent about an hour going through code trying to work out why I wasn’t getting any response from the server - I forgot that I had commented-out the URLLoader.load() line in one of my classes while I was debugging some other parts of the app. It always ends up being a dumb human error. smilie

Publishing for FP10 isn’t too bad at the moment but [depending on your target audience] it could be better. FP10 distribution is around the 75% mark at the moment according to Adobe.

  • 09 June 2009 01:31 PM
    •  

Page 1 of 2