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.

a great community.

[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.

[Polaco]

I have found this article:
http://www.defusion.org.uk/archives/...lex-and-rails/
maybe provides some help. Haven't tried it yet. Maybe on tuesday.

[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).

[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.

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!

[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.

[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.

[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 .
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!

[Polaco]

Oh no! damn!

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

Connection to
http://10.15.64.206:8001/portal/site...tte.cachetoken
halted - not permitted from
http://10.15.64.206:8001/repository/...ageGallery.swf

--------------------------
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.

[Nutrox]

Have you tried it without the port numbers?

[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

[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

[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.

[Nutrox]

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

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?

[Polaco]

Hi Si, I feel a bit stupid now more than I regulary feel.
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.

[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.

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.

[Polaco]

Oh! that commenting thing has happened to me 1000 times.
The target audience are users of an intranet corporation, I'm pretty sure they have it installed but I can't remember that on the thechnical design I wrote that the FP requiered was 9. Anyway I guess it will be not a big problem.

I wondered if you know how to listen to the uploaded data progress of a URLLoader object since in Adobe docs says:

"progress:ProgressEvent — Dispatched when data is received as the download operation progresses."

maybe it's not possible?
http://bugs.adobe.com/jira/browse/FP-1959

[Nutrox]

I don't think it is possible with a URLLoader, you can track the progress of uploads if you use a FileReference.

[Polaco]

but FileReference has the problems commented before..

[Polaco]

Well it seems to be no possible. So I will make a fake progress bar and wait for the server response to comfirm the upload. It's not soo cool but at least it works.
I will also include a bit of code in case it could be useful for someone.

thanks a lot for your care Si!

[Polaco]

Oh!, for the tremendous joy of developers:
http://kb2.adobe.com/cps/405/kb405546.html
So, you can't upload multiple files secuentially in this way using URLLoader.
I guess in case you have to upload 100 images you must invoke 100 urlloaders at the same time.Instead of loading them secuencially.
Of course FileReference doesn't have this restriction, but doesn't send any session data so is usless for many people who has to upload files under an https environment or with authentication under plain http.
It's really strange the FileReference behavior since other flash.net objects works perfectly under same conditions. Either I can't understand this kind of extreme and unnecessary security restrictions that lumber the player API, developement tasks and the end user capabilities.
It would be great that Adobe reconsider all this tons of pointless restrictions and deliver a refactored API that has a common way to handle this kinds of things for the next flash player release. Which I hope it wouldn't be too far away from now and thus late.


just a wish...