XUL:Remote XUL bugs: Difference between revisions

Jump to navigation Jump to search
Line 40: Line 40:
Rationale: This is already possible with a html input type="file" inside the XUL.  That is, create a HTML input type=file, which would then post the file to the remote server.  The file could then be retrieved from the server by using xmlhttprequest.  This doesn't scale well, and the end result is the same.  Using something like [http://www.quirksmode.org/dom/inputfile.html this] and some more CSS could probably even get the input to look exactly like it was just another XUL element.  I also don't think it is a really big security issue, since the only file the remote script would be able to read would be the one the user selected.
Rationale: This is already possible with a html input type="file" inside the XUL.  That is, create a HTML input type=file, which would then post the file to the remote server.  The file could then be retrieved from the server by using xmlhttprequest.  This doesn't scale well, and the end result is the same.  Using something like [http://www.quirksmode.org/dom/inputfile.html this] and some more CSS could probably even get the input to look exactly like it was just another XUL element.  I also don't think it is a really big security issue, since the only file the remote script would be able to read would be the one the user selected.


A file save dialog would be similar to the above, allowing a remote script to present a javascript string to be saved or an output stream or something.  I am not as sure about this, since it might be possible to load the data into a hidden iframe and then call the document.execCommand('SaveAs',null,filename) command.  Again, this seems possible already.  
A file save dialog would be similar to the above, allowing a remote script to present a javascript string to be saved or an output stream or something.  I am not as sure about this, since it might be possible to load the data into a hidden iframe and then call the document.execCommand('SaveAs',null,filename) command.  Again, this seems possible already.
 
(Ben Bucksch) I agree that this would be secure, if implemented correctly and the dialog makes the user aware whom they are giving the file content to. Compare [http://www.jnode.org/node/900 my security proposal for JNode]. However, this is an RFE (not a Mozilla bug) and probably quite some work.


= Not a bug =
= Not a bug =
Confirmed users
591

edits

Navigation menu