Sunday, August 01, 2004
Creating Remote Mozilla XUL Applications
Man, this is cool. This weekend I was just playing around with what it would look like to remotely generate XUL from JSP applications for integration into Mozilla, just to see what that application model looks like. One issue is that the security model in Mozilla gets kinda complex in that scenario, but I finally found a way to allow remote XUL apps to access the full Mozilla XPCOM system. First, you need to edit your prefs.js file that is in your profile directory (this is in different places on different operating systems; on my Windows box it is in C:\Documents and Settings\bradneuberg\Application Data\Mozilla\Firefox\Profiles\default.9m8\). Add the following lines to the bottom of this file _while Firefox is not running_:
user_pref("signed.applets.codebase_principal_support", true);
user_pref("capability.principal.codebase.fullaccess.id", "http://localhost:8080");
user_pref("capability.principal.codebase.fullaccess.granted", "UniversalXPConnect");
The 'fullaccess' part is the name of your application; change it to the name of your app; also change the "http://localhost:8080" to the location of where your app will remotely generate XUL. This will be the URL that will be given XPCOM privileges.
Now, in your remote XUL, whenever you want to call a trusted XPCOM method or part of the Mozilla Application Object Model that is protected add the following line _in each JavaScript function_ that you want to be privileged:
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
What this does is give _just that JavaScript function_ the privilege asked for, so remember to put it into each function.
The first time a user runs your remote XUL app that has this line they will be prompted on whether to give your app permision to have full access.
One issue is how do you get those lines I gave above into the user's pref.js without having to manually add them. One way would be to create a small XPI download that adds them dynamically, but that is not really a satisfactory way to do things. Anyone have any ideas?
user_pref("signed.applets.codebase_principal_support", true);
user_pref("capability.principal.codebase.fullaccess.id", "http://localhost:8080");
user_pref("capability.principal.codebase.fullaccess.granted", "UniversalXPConnect");
The 'fullaccess' part is the name of your application; change it to the name of your app; also change the "http://localhost:8080" to the location of where your app will remotely generate XUL. This will be the URL that will be given XPCOM privileges.
Now, in your remote XUL, whenever you want to call a trusted XPCOM method or part of the Mozilla Application Object Model that is protected add the following line _in each JavaScript function_ that you want to be privileged:
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
What this does is give _just that JavaScript function_ the privilege asked for, so remember to put it into each function.
The first time a user runs your remote XUL app that has this line they will be prompted on whether to give your app permision to have full access.
One issue is how do you get those lines I gave above into the user's pref.js without having to manually add them. One way would be to create a small XPI download that adds them dynamically, but that is not really a satisfactory way to do things. Anyone have any ideas?
Comments:
Links to this post:
<< Home
You should never be telling any user to enable the codebase principal pref. It reduces the user's security by allowing unsigned code to do anything with only one click.
/ Neil
/ Neil
# posted by 
: 8:47 AM
: 8:47 AM
Neil, do those prefs completely open up the XPConnect system to all code, or do they only open it up to the domain given? I had the impression that the last two prefs only open it up for the ID given. Also, what exactly does the signed.applets.codebase_principal_support pref enable? I've read that it enables code to be downloaded with a certificate; is this for all code?
By the way, I don't recommend the procedure I gave for anything other than during development. I still need to find a more secure way to enable these things on actual deployment. One issue is that the official way to do secure remote XUL, as a signed JAR file, can't be done when you want to dynamically generate the XUL at runtime, such as from data in a database. Any suggestions for what to do in a dynamicly generated XUL scenario?
By the way, I don't recommend the procedure I gave for anything other than during development. I still need to find a more secure way to enable these things on actual deployment. One issue is that the official way to do secure remote XUL, as a signed JAR file, can't be done when you want to dynamically generate the XUL at runtime, such as from data in a database. Any suggestions for what to do in a dynamicly generated XUL scenario?
Brad;
How cool that you notice all the hidden little things put out there. It's like looking through a microscope at the world.
Post a Comment
How cool that you notice all the hidden little things put out there. It's like looking through a microscope at the world.
Links to this post:
<< Home
Subscribe to Posts [Atom]
