Xul, XpCom, Security, and A Mozilla Newbie
James Warner
I've been unable to find any definitive documentation and my own Xul
experiments have left me somewhat confused.
Anyway, my question is whether it is possible to disable the security
manager so that Xul files can be sent over an http url and then
execute XpCom style interface's inside of the JavaScript code
associated with that Xul file. I know that I can use chrome to
accomplish such a thing if the chrome is set up properly inside of the
mozilla chrome directory, but that is a different thing entirely than
doing it over http. Anyway ideally what I would like to be able to do
is get the Xul Data over http and post it back to another application
listening on a different Socket. I have seen references to remote
chrome, which looks like it allows for sending Xul remotely, but I am
wondering what setup is required to allow remote chrome and if it
allows for executing XpConnect/XpCom interfaces or if that is
prohibited as well?
BTW I do realize that from a Web Browser security standpoint this is
not a desirable thing to do, but from the implementation of a
generalized application's development toolkit it would seem that being
able to do something like this would be desirable (at least for my
current project it seem's like a great thing to do).
Thank's in Advance for the Input,
James Warner
mailto:fr...@delanet.com
Mitchell Stoltz
Remote chrome is a proposed feature that hasn't actually been
implemented yet. It is possible to configure Mozilla to allow remote XUL
files (loaded as content, not as chrome) to call XPCOM interfaces. Try
adding these lines to the prefs.js file in your user profile directory
while Mozilla is not running:
user_pref("signed.applets.codebase_principal_support", true);
user_pref("capability.principal.codebase.fullaccess.id",
"http://myhost.com:1234");
user_pref("capability.principal.codebase.fullaccess.granted",
"UniversalXPConnect");
Replace "http://myhost.com:1234" with the hostname and port from which
your xul content will be served. "http://localhost:1234" should work
fine if that's what you're using.
good luck,
Mitch Stoltz
Stuart Ballard
>
> James,
> Remote chrome is a proposed feature that hasn't actually been
> implemented yet. It is possible to configure Mozilla to allow remote XUL
> files (loaded as content, not as chrome) to call XPCOM interfaces. Try
> adding these lines to the prefs.js file in your user profile directory
> while Mozilla is not running:
Just curious...
What would putting http: urls in installed-chrome.txt instead of file:
urls do?
Stuart.
--
Stuart Ballard, Programmer
FASTNET - Internet Solutions
215.283.2300, ext. 126
www.fast.net
James Warner
Thanks for the help so far, but due to my complete incompetence it
doesn't quite seem to be enough yet, so if you could find your way
clear to help me just a little bit more it would be much appreciated.
So what I have tried so far is the following:
I added the following lines to my prefs.js file, but I still get a
Permission denied to get property Unknownclass.classesById. The lines
as they show up currently in my prefs.js file are:
user_pref("capability.principal.codebase.fullaccess.granted",
"UniversalXPConnect");
user_pref("capability.principal.codebase.fullaccess.id",
"http://slbdhcp075:8384");
user_pref("signed.applets.codebase_principal_support", true);
The relevant code as it shows up in the javascript file is:
###### Begin Code Snippet ################
var sockServiceClass =
Components.classesByID["{c07e81e0-ef12-11d2-92b6-00105a1b0d64}"];
if (!sockServiceClass)
throw ("Couldn't get socket service class.");
var sockService = sockServiceClass.getService();
if (!sockService)
throw ("Couldn't get socket service.");
this._sockService = sockService.QueryInterface
(Components.interfaces.nsISocketTransportService);
// to preserve ourselves within necko/async
this.wrappedJSObject = this;
##### End Code Snippet ###################
Finally, in reading through your previous post I realized that I don't
quite know the difference between loading a javascript interface as
content vs. chrome, which may well be the problem. So, if you could
help clarify the difference or point me to the relevant documentation
that would be great.
Thanks Again,
James Warner
mailto:fr...@delanet.com
Mitchell Stoltz <mst...@netscape.com> wrote in message news:<3C3F3692...@netscape.com>...
James Warner
It turns out that I needed to add
netscape.security.PrivilegeManager.enablePrivilege
("UniversalXPConnect");
back into the function that was creating accessing the socket
Interface.
Otherwise those lines added to ther prefs.js file were the ticket.
Thanks Again for the help,
James Warner
fr...@delanet.com
Mitchell Stoltz <mst...@netscape.com> wrote in message news:<3C3F3692...@netscape.com>...