Closed Bug 722126 Opened 9 years ago Closed 5 years ago
Can't transfer File objects with post
Message cross domain
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Build ID: 20111220165912 Steps to reproduce: I two scripts on two different domains (postmessagea.s3.amazonaws.com (A) and postmessageb.s3.amazonaws.com (B)). I navigate to A/A.html and select a file. The submit posts a message to B/B.html. The message contains the File object selected in the input element. View code within attached zip file to reproduce the issue. Actual results: The script A/A.js fails when sending the file object via postMessage. "The object could not be cloned." Expected results: The file object should be transferred to B/B.js.
Sorry, missing word in first sentence--I *host* two scripts on two different domains.
A follow up question--how can I test for availability of this feature without requiring the user to select a file and then click submit? Is there a "fake" file object that I can instantiate and attempt to post to the script on the other domain, or do I simply have to wrap the whole thing in a try-catch block?
Just tested, fails on FF10 as well.
Version: 9 Branch → 10 Branch
Component: Untriaged → DOM
Product: Firefox → Core
QA Contact: untriaged → general
(In reply to dan from comment #2) > A follow up question--how can I test for availability of this feature > without requiring the user to select a file and then click submit? Is there > a "fake" file object that I can instantiate and attempt to post to the > script on the other domain, or do I simply have to wrap the whole thing in a > try-catch block? You can use BlobBuilder to construct a blob you can use to check.
8 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86 → All
Version: 10 Branch → Trunk
8 years ago
Depends on: 673742
This should be scheduled for a group review and include Jonas
I have just updated the example code to show how you can reconstruct the blob on the receiving frame, without any data loss. If this is indeed a security issue (and I hope it's not because I need to use this feature for direct-to-s3 uploads!), then it's almost impossible to circumvent as long as BlobBuilder + ArrayBuffer + postMessage exists. Just go to http://postmessagea.s3.amazonaws.com/A.html, browse to a file, and open up Firebug. Click "send file" to see the bug, then click "send contents and reconstruct file via blobbuilder" to see how it can be circumvented.
I should add that FileReader is a necessary component as well. But given those 4 tools, file transfer cross domain can be achieved no matter what.
Depends on: 744538
When ready for security review please reply to comment 0 in bug 744438
Whiteboard: [secr:curtisk] → [secr:curtisk:744538]
sorry that should have been 744538
Whiteboard: [secr:curtisk:744538] → [sec-assigned:curtisk:744538]
Is this bug still being worked on? Sort of getting tired of having to have to explain to developers why there is a separate code path for Firefox to convert Blobs to ArrayBuffers before postMessages. One of the main examples of an Eclipse Orion plugin that we work on at hackathons is writing fileservice extensions and the inability to pass Blobs without first converting to an ArrayBuffer is a significant stumbling block.
Still need to write a test.
Assignee: nobody → khuey
Status: NEW → ASSIGNED
Attachment #681143 - Flags: review?(jonas)
Comment on attachment 681143 [details] [diff] [review] Just do it r=me if you add a test
Attachment #681143 - Flags: review?(jonas) → review+
:sicking - is this ready for the security team to take a look at it?
Yes. And it's ready for Kyle to land once he gets of his keaster :-)
When can we get a secreview scheduled for this?
I don't think it needs a sec review. We should just land it. You can always transfer this data via other means as stated in comment 12.
(In reply to Kyle Huey [:khuey] (firstname.lastname@example.org) from comment #18) > I don't think it needs a sec review. We should just land it. You can > always transfer this data via other means as stated in comment 12. dveditz thought we needed to do a team review of this one, but it's been so long flagged that I can't remember his concerns, if he is fine with removing the sec-review flag then this can pass by, otherwise we need to find a time to talk this one through with the team
As long as we're cloning the data and not sharing it should be fine.
These objects are immutable, so it doesn't really matter.
per spec that is true. per implementation it is not though for a File coming from <input type=file>.
Was going to report this bug. Was nice to see it's been fixed already. The security issue (bug 744538) is marked as resolved, and from the comments it sounds like it's nothing else stopping this from being merged. Would be nice if this could land soon :)
I got pinged about this on twitter the other day. I actually don't think this patch works anymore, because it depends on the old XPConnect behavior of creating a wrapper for each scope for things that aren't wrapper cached. I think we need to create a clone of the FileList in the new scope.
been 2.5 year now since this was reported. Is anyone looking into this?
Running into the same issue, also in Nightly. Apart from fetching the file content into an ArrayBuffer, is there a simpler solution available?
Andrea, want to have a look at this? Should be trivial to get this patch working I would think.
That is what baku is doing in Bug 1185360.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1185360
You need to log in before you can comment on or make changes to this bug.