XUL and netscape.security.PrivilegeManager.enablePrivilege()

Discuss building things with or for the Mozilla Platform.
deepgloat
Posts: 20
Joined: June 22nd, 2004, 6:49 am

XUL and netscape.security.PrivilegeManager.enablePrivilege()

Post by deepgloat »

I am really at the end of my rope with an XUL problem in Mozilla 1.7, and I'm hoping someone in here will be able to point out what I'm doing wrong.

A little background: I reported this bug in Mozilla 1.7 (or what I thought was a bug) with remote XUL windows ignoring the title, width and height attributes. Turns out that Mozilla 1.7 restricts unsigned remote XUL from setting these attributes.

Signing scripts and XUL constantly while developing an application would be a ridiculous pain in the neck, so I tried the other suggestion I was given: call the netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserWrite") function:

Code: Select all

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<style>
</style>
<script>
function loadxul() {
    netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserWrite");
    window.open("test.xul","test","chrome,resizable,centerscreen,dependent,dialog");
}
</script>
</head>
<body>
<input type="button" value="Load XUL Test Window" onclick="loadxul()">
</body>
</html>


Well, I tried that and it works fine if I'm opening the HTML page with the "file://" protocol. But if I actually deploy the above HTML page to our Apache server, navigate to it with the "http://" protocol, and try the same function again, I get the following security exception:

A script from "http://localhost" was denied UniversalBrowserWrite privileges.'' thrown from function loadxul() in <http://localhost/xul/index.html> line 8.

Please tell me that I'm missing a step here and point out what it is. If I have to tell my boss that we will have to sign all HTML, JavaScript and XUL just for testing purposes, he's going to kill our entire XUL proof-of-concept project. He's already incredulous that Mozilla no longer allows setting the width, height and title attributes--this would be the final nail in the coffin for using Mozilla as a development platform.

Thanks.
deepgloat
Posts: 20
Joined: June 22nd, 2004, 6:49 am

Post by deepgloat »

Never mind. I stumbled across the problem... our developers have to add this line to the defaults\pref\browser-prefs.js file in their Mozilla installation directory:

Code: Select all

pref("signed.applets.codebase_principal_support", true);


This may still wind up causing our XUL pilot project to get scuttled. We were looking for a zero-client-install solution which XUL used to offer, but now it looks like we're going to have to tell customers who buy our ERP software to either
  • edit their browser-prefs.js file like I did above,
  • sign the files that we deliver to them, or
  • abandon the zero-install concept and design the system to be installed in the chrome.
None of these are acceptable solutions. Mozilla is really shooting themselves in the foot here, from our perspective.

:mad:
TheOneKEA
Posts: 4864
Joined: October 16th, 2003, 5:47 am
Location: Somewhere in London, riding the Underground

Post by TheOneKEA »

Why not create an extension which embeds the ERP application inside the browser? The ReGet Download Manager software has an XPI plugin for Firefox which provides a way to directly invoke ReGet from the browser - can the same be done for your application?

If you want more information about the ReGet plugin, contact a guy named Flexer here on the forums.
Proud user of teh Fox of Fire
Registered Linux User #289618
deepgloat
Posts: 20
Joined: June 22nd, 2004, 6:49 am

Post by deepgloat »

We have a zero-client-install design requirement. Installing anything on the browser is verboten.

I have also just discovered that the instructions for signing scripts are over two years old and don't work with Mozilla 1.7, so now signing XUL isn't even an option. (Hell, the instructions for how to add the "signed.applets.codebase_principal_support" pref were wrong as well--it took sleuthing through the installation files and some experimentation to figure out how to do it. GRR!)

I used to be really excited about using XUL for our front-end UI, but the Mozilla Foundation developers in charge of XUL just don't seem to care about how XUL is being crippled for development use. If mere mortal developers like me can't sign scripts and use XUL effectively, how can anyone expect XUL to be viewed seriously as a cross-platform GUI?
TheOneKEA
Posts: 4864
Joined: October 16th, 2003, 5:47 am
Location: Somewhere in London, riding the Underground

Post by TheOneKEA »

Security.

Enabling signed.applets.codebase_principal_support makes the browser vulnerable to script attacks and other nasty things.

Sorry.
Proud user of teh Fox of Fire
Registered Linux User #289618
User avatar
MonkeeSage
Posts: 1011
Joined: December 20th, 2002, 8:15 pm

Post by MonkeeSage »

deepgloat wrote:I used to be really excited about using XUL for our front-end UI, but the Mozilla Foundation developers in charge of XUL just don't seem to care about how XUL is being crippled for development use. If mere mortal developers like me can't sign scripts and use XUL effectively, how can anyone expect XUL to be viewed seriously as a cross-platform GUI?


I think the problem comes from your expectations. You are expecting to make a web-app (for all intents and purposes) which is silently given chrome permissions. If you make an extension (or even a Java program [using the XPConnect interfaces]) then you can [silently] operate in the chrome context with full permissions. But it would be insane to allow access to XPCOM components from anything other than chrome or explicitly permissioned scripts. Just visiting the wrong site or clicking the wrong local file could delete all the files from your drive, change registry settings, &c.


Shelumi`El
Jordan

S.D.G
"[M]en are usually satisfied with bad argument only when their convictions rest on other grounds." --John Oman
deepgloat
Posts: 20
Joined: June 22nd, 2004, 6:49 am

Post by deepgloat »

Sorry, I guess I wasn't being clear enough.

I'm trying to enable signed.applets.codebase_principal_support just so my team of developers working on our pilot project can get back to work. I am fully aware that this is an unacceptable final solution for deployment (I even said it was an unacceptable solution in my "never mind" post).

The real issue is the fact that Mozilla's instructions for how to sign remote XUL don't work with Mozilla 1.7, which may wind up scuttling our proof-of-concept project before it's even finished. Management isn't going to give the go-ahead to begin XUL front-end development if there's no way for our customers to deploy it.
jedbro
Posts: 1899
Joined: November 10th, 2002, 12:35 pm
Location: Mexico / Boulder Co.
Contact:

Post by jedbro »

Have you contacted the Doc author?

I'm sure he would be willing to help you if he knows how.
deepgloat
Posts: 20
Joined: June 22nd, 2004, 6:49 am

Post by deepgloat »

^^^ I managed to puzzle out the instructions. The problem is that signing a JAR containing your XUL and JavaScript doesn't work--the XUL is still displayed in a browser window that doesn't allow sizing control, and the title attribute of the window is still inaccessible. Looks like a bug to me...
jeremyf
Posts: 5
Joined: February 13th, 2004, 2:22 am

Post by jeremyf »

Deepgloat,

I have been following your problem on XULPlanet and find I have the same problem. I am looking at using XUL as a web app which, if accepted, would require distribution to our customers. This would involve approx 500 desktops at 30 different sites. Releasing patches would be a nightmare if the app was installed in chrome. Ideally, geko/mozilla would have some sort of system in place that would allow patching either from a local server or from a remote server. As an alternative have you considered having a small app installed in chrome that checks the server for updates and literally copies the jar file over the current jar file, installed in chrome?

Jeremy
Ecthellion
Posts: 3
Joined: June 12th, 2004, 8:37 am

Signing docs on the way out of the webserver

Post by Ecthellion »

I work at a small web-development firm that has found itself mostly doing custom business apps and as I (and several others of us) have been big Firefox fans for a while we wanted to try doing some XUL stuff to make the experience smoother and more interactive. We come from a background of doing everything in html server side so some of the stuff we have found in XUL is quite refreshing but we have also hit the permissions wall as well.

Looking at the information on signing the app has been giving me some misgivings. As deepgloat has pointed out, the docs are somewhat out of date on this front, and only talk about signing a compile jar file.

Turning off the permissions system through the preferences seems like a rather poor solution. We don't really want to package this as an extension, as deepgloat pointed out sometimes that isn't an option.

Packaging as a signed jar is only slightly preferable. We would like to keep the capacity to dynamically generate the content that gets sent to the client. This is far less necessary in XUL than it is in HTML, but we still think this would provide some nifty capability.

So the question is: does anyone know if it is possible to set it up to sign individual documents on the way out from the webserver. Would these documents be able to reference eachother with full permission? e.g. will I be able to instantiate the rdf objects to query the rdf data the server is generating? As far as I understand it, the digital signature is packaged as part of the jar, is this right? If so then it would be hard to just sign the document without any modifications as how would the digital signature get passed along. Possibly jar and sign each document on the way out and then reference between those?

jeremyf: Firefox now has a nifty autoupdate system, if installing as an extension isn't otherwise a problem that might help out the updating problem.
jeremyf
Posts: 5
Joined: February 13th, 2004, 2:22 am

Post by jeremyf »

Unfortunately, the autoupdate feature is not really an option. The initial install is a user base of approx 1200 users located in ~40 locations across the UK. What both myself and deepgloat are looking for is the ability to serve remote applications with either signed scripts or where the serving domain, in this case an intranet server, is trusted to allow chrome equivalent access. Mozilla/Firefox show that they are good tools for application development but they would be even better for remote application development. There are a lot of people/companies interested in using xul in this fashion but the lack of working zero-install is stopping most.

Jeremy
erdnase
Posts: 1
Joined: November 13th, 2004, 2:48 pm

signing XUL

Post by erdnase »

has any progress been made on this issue? i've written a XUL toolbar for my users because i thought it would save them the confusion of using a javascript bookmarklet ("drag the link to your browser toolbar, NO, DON'T CLICK IT! arg...").

but i'm hitting the same speed-bump described below -- installing the XPI file warns the user about unsigned code, and dims the "INSTALL" button for several seconds to further dissuade the user. this is the exact OPPOSITE behavior we want!

what are my options?

thanks,

-- jm3
ketket
Posts: 1
Joined: November 17th, 2004, 4:34 am

can't open chromless mozilla in linux but can in windows...

Post by ketket »

Hi,

with above given suggestions I can open chromless mozilla window in Windows2000 but if i do same thing on Linux, it still open with chromes and title bar, which I do not want to appear. I am using redhat ES linux and Mozilla 1.7 .. can anybody help...Thanks in advance.

Ketan
chronologic
Posts: 1
Joined: May 8th, 2007, 7:27 pm

Don't even try

Post by chronologic »

Your problem is you are trying to write an application in a web browser. Don't do it. The idiots that write web browsers are creating toolsets to try to entice you...but don't believe them!! It's crap. Web browsers can't do applications. Why would you spend your time trying to piece together a bunch of hodge-podge tools that barely work at all, never ever conform to anyone's specifications except the particular developer who implemented the feature, and leave you completely unable to do ANYTHING.

You don't believe me? Look at this:
https://bugzilla.mozilla.org/show_bug.cgi?id=190515
Comment#3:
"I deliberately did not add a confirmation dialog, because I think they're
annoying and detract from the user experience."

Yeah I know. You THINK. To HELL with the docs at http://developer.netscape.com/docs/manu ... tm#1201822

They're outdated. So...where are the new ones that say you're right my man? Or did you write those? I know that what you think is important. So I guess the rest of us are just screwed. After all, there are hackers and crackers out there that REALLY WANT to close down your browser window. I bet their favorite is when you keep coming back so they can keep closing it. That's so great. Of course the one thing that sucks from their perspective is that if they close your window, well, you're gone. They can't do anything else nasty. But still, you THINK it's a bad idea and you THINK it's not worth a dialog box so screw it. Ok buddy you and your ego can have it your way.

Exactly. Why is it like this? Because it's the web man! You can't be trusted! Don't try to close any windows or remove any toolbars or anything. The user wants to hit back? Guess what, the user gets to hit back! If you have to write 20,000 more lines of code to try to deal with all the states that will arise from the inherently stateless design, that's your problem not the browser's. You want to test your code against IE, Firefox, Opera, you name it? Good luck man. OH you think you're ok because your company only uses IE...I see. Well, just make sure you don't write too much code because when IEvNext comes out you're going to have to be rewritin' it. I bet if you try REALLY HARD you could probably piece together enough HTML, JAVASCRIPT, XML, PHP etc to get an application that only KIND OF SUCKS. It MIGHT be able to do SOME of what a real application can do and if your users are really gentle and don't push any buttons while the page is still loading and they don't hit back and forward instead of your controlled navigation buttons maybe things will work sometimes. Oh I'm sure you can deal with that. All it takes is lots more creative code! Come on buddy you can be creative right? You don't have a wife or family or anything right? -- I know you want to write code 20 hours a day. Maybe more!! And what do we love even more than writing code? Testing! Especially regression testing. I just love it when I fix code for IE that breaks in Firefox. And then when I fix the Firefox, it breaks the Palm Blazer, and after that, I go fix Palm Blazer and IE is broken. Soooo FUN!!!!! I'd rather do that than play Zelda any day. I don't need to ride my bike or go for a walk with the dog. Not necessary.

But how stupid are we? Are we seriously dumb enough to keep doing this? I ask myself every day that same question. "Web Applications" are the stupidest thing I've ever seen in my technical career. I have never before seen so many people so deluded. It's a DUMB IDEA folks and that's all there is to it.

You want to make a real application? Stop screwing around with .NET Schmuck and AJAX wipe. We don't need no javascriptation. We don't need no code control. Shut the crap up and go use Java. Java Applets rock. With Java you no longer have to come up with "creative" ways to do the obvious simple stuff. You no longer have to screw around with trying to get your UI to render in 3 different browsers. You have a REAL toolkit, with real ability to get the permissions needed to do ANYTHING YOU WANT. Full GDI capability, you can render anything you want and it will load right up. Use web services (ala ajax but without the lowercase and STUPID j -- I'm talking aJax - now we're on to something). Why would anyone want to keep using piece of crap HTML and piece of crap javascript to try to write a reasonable application? Are we just masochistic? I can see no other option. It's asinine to screw around with making a real application with such bullshit tools. It's like trying to build a space shuttle with some pieces of leather, some cow brains, spit, urine and a few rocks. Stupid.

Don't waste your time with browsers. Don't be stupid. You think the guy that invented HTML intended for you to be screwing around with it like that? It's a really bad case of evolution gone haywire. We are off the trail. It's ok, check your compass, retrace your steps. I'm sure we can get back on track. I think it started somewhere back around http://yoursite.com/index.html. That seems to me like the first wrong move.

Run in a VM like Java and flash and once again you can stop screwing around and start writing code that matters. You will not catch me building another app for a browser ever again in my life. I hope you, dear reader, are smart enough to turn 180 right now.

So although for now I am paid to be just as pissed of as you are, my answer is screw browsers. When this project is over I'm done with this bullshit. If you're smart that will be your answer to.

Just two cents from one experienced web developer who's sick and tired of it. The web, the internet, it's awesome and I really mean that. But if you want to write a business application, there are better ways to do it!

Believe it or not I'm not taken to rants but I am just fed up. Up to my ears in bullshit.
Locked