1
edit
XUL:Remote XUL bugs: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(remove vandalism) |
No edit summary |
||
| Line 48: | Line 48: | ||
: '''Rational:''' 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. | : '''Rational:''' 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. This 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. This 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. | ||
(Jocelyn Raymond) Remove Privilege or Remote Privilege? I am not sure, but perhaps the title has a typo. I came from [http://wiki.mozilla.org/XUL:Priority_List] where it says for anyone to discuss "Remote" XUL application to come here. Anyway, I would like to add some discussion on remote XUL here (feel free to re-direct this if necessary). (Please, excuse my English , I am French). | |||
First, I have been looking at XUL for about a year and build actual XUL application for the past 6 months. All future XUL applications that I must build have to be remote (like the first one I builded). Moreover, all XUL applications that I will be building are for our intranet (or in-house applications). Thus the problem of "privileged" tasks/resources is important to me. I will get right to the point and please do correct/expend this if you can. | |||
What I would like to see for remote XUL application is the ability to add in the preference "signed.applets.codebase_principal_support" (or perhaps a specific privilege such as XPConnect) a domain[/path] (where [/path] means is optional). | |||
Thus, if I could add this preference, it would essentially mean "Any XUL application coming from www.mydomain.com/path/to/my/app is granted XPConnect". Of course, this is not useful for anyone that wish to develop for an unknown audience (such as the internet), but only for secure controlled intranet. | |||
Would something like this be feasible? Would it be secure enough? | |||
Of course, I think the best is to sign our remote XUL application which I did without success (i.e. the signed code was treated as if it was invalid so I must have done something wrong along the way). There is much more I would like to say but not sure this is the appropriate place. | |||