Tài liệu Creating Applications with Mozilla-Chapter 12. Remote Applications-P4 docx

Chapter 12. Remote Applications-P4 Figure 12-5. Downloading a certificate window After the certificate is installed, it will appear in the Certificate Manager, as shown in Figure 12-6 . The Certificate Manager can be accessed via the global Mozilla preferences (Edit > Preferences > Privacy & Security > Certificates). Mozilla is then ready to run signed remote Mozilla applications bearing signatures from your certificate authority. Figure 12-6. Certificate manager with a certs.mozdev.org CA certificate 12.6. Creating Signed Remote Applications Security in Mozilla's web browser is designed to meet today's advanced scripting needs in a secure manner. Mozilla is a much more secure browser than past Netscape 4.x and Internet Explorer releases because it has a better sense of what remote scripts can and cannot do. Because of Mozilla's approach toward potentially insecure applications, if you decide to serve up your own application remotely, remember that you will not have automatic access to the chrome in the way you do when you have a registered, locally installed Mozilla application. Unless you sign your application or have the user turn on a special preference (see Section 12.3 ), services like XPConnect will not be available. In Mozilla, you can bundle any number of files into a JAR archive (which, you'll recall from Chapter 6 , is just a zip file with a JAR suffix) and designate the archive as an object that can be signed. This designation makes it very easy to produce an entire signed and secure remote Mozilla application because it stores your application in a single file type that Mozilla already treats as a separate package. This section provides an overview of the signed script technology and shows you how to create signed applications that live on the server but take full advantage of the user's local chrome, including Mozilla components. 12.6.1. certs.mozdev.org CA Certificate Before users can load signed applications, a CA certificate must be installed into their installed copy of Mozilla. Once this certificate is installed in a browser, all MozDev-signed applications can work with this certificate. This setup makes things easier on users who access many of these signed applications because they do not have to install a new certificate for each one. Also, if the user wants to use applications from other certificate authorities, they need to install a distribution certificate from that certificate authority. Installing the certificate is easy. Just provide the users with a regular link on a web page for example, http://certs.mozdev.org/certs_mozdev.cacert. When loading this page, a dialog box pops up and asks the user to install the certificate. See the Section 12.6.3.2 section later in this chapter for more information about this process. 12.6.2. Signing Certificates As a Mozilla application developer, you can obtain a common MozDev signing certificate and release a signed application that puts your application on par with other signed MozDev applications. If you consider your application mission-critical, however, you should go to a trusted CA such as Verisign. Mozilla already supports the VeriSign Netscape Object Signing CA, and discriminating users may find it more acceptable. A few other CAs listed in Mozilla's Certificate Manager may support Netscape Object Signing, so researching these options further may be worthwhile. To get a certs.mozdev.org/signing certificate, send email to cert- request@mozdev.org. In return, you will receive a .cacert file that will be used to sign your remote Mozilla application. SignTool (part of the NSS tool sets) takes a directory of files, zips them up into a JAR archive (refer to the section Section 12.6.3.1 later in this chapter to see how to do this), and signs the archive using the certificate you specify. SignTool comes with the latest release of NSS, Version 3.4.1. On http://certs.mozdev.org, limited functionality versions of NSS contain SignTool for Windows and Linux that you can use instead for the processes in this book. Use CertUtil to set up a database for SignTool. Next, run some commands to set up the certificate environment: C:\NSS\bin>certutil -N -d . C:\NSS\bin>certutil -A -n "certs.mozdev.org/signing" -t ",,C" -i eric.cacert -d . The first command creates an empty cert7.db file where certificates can be stored. The second imports your Signing Certificate into the database. SignTool can use only certificates that reside in a database, which is the reason for this process. 12.6.3. Creating and Signing the Application When someone obtains a private key (which is part of a Signing Certificate), they can encrypt their scripts and produce a public key. The relationship of the private key and the public key is called a private-public key pair. Using this relationship, you can create a signed Mozilla application and make it available to users in three steps: 1. Build the application itself, including the XUL, CSS, JavaScript, and whatever else you use to create the Mozilla application. For this section, let's assume that you already created the XUL and JavaScript for the application and have all the files and directories together. 2. Archive and sign the application. SignTool takes care of both steps simultaneously, putting your application files in a JAR with a digital signature to validate everything. The signing process described next in Section 12.6.3.1 deals entirely with SignTool. 3. Distribute your application (see the later section Section 12.6.3.2 ). 12.6.3.1. Signing the application Security is not simple. Security technologists and vendors work hard to make sure that evildoers cannot abuse their encryption schemes, keys, and other tricks. Tools like SignTool can hide some of this complexity from you. When you sign an application, you create a digital signature in the archive that is based on the relationship of the files being signed, as Figure 12-7 illustrates. Figure 12-7. SignTool's processes for creating a signed application SignTool automates these steps for you, so you don't worry about them. However, knowing these processes and seeing how these transactions take place can be useful, especially since using signed applications with Mozilla doesn't always work as expected and long-term directions for signed applications in Mozilla are uncertain. This uncertainty makes long-term deployment of signed remote Mozilla applications a risky option. To start off your remote Mozilla signed application development, you can do something as simple as place one XUL and one JavaScript file in a single directory. Then move it into a NSS bin directory such as C:\NSS\bin and issue the command: C:\NSS\bin>signtool -d . - k"certs.mozdev.org/signing" -p"password_of_database" -Z"myapp.jar" myappfiles/ The -d option is where the certificate database resides and -k is the certificate name. 12.6.3.2. Distributing the application Once the file is created from the -Z option (e.g., myapp.jar from the example above), you can put it online. On the application's web page, note that the application is signed and put a link to http://certs.mozdev.org/certs_mozdev.cacert so users can install the necessary MozDev certificate if they do not have it. To access the application online, you must use a special URL format. This format looks like jar:http://certs.mozdev.org/myapp.jar!/myapp.xul and points into the JAR at the main application file. This URL is difficult to type, so it may be wise to link it for user access or set up a redirected URL to that address, as shown in Example 12-12 . Example 12-12. Sample redirect into a signed application <HTML> <HEAD> <META HTTP-EQUIV="REFRESH" CONTENT="0; URL= jar:http://certs.mozdev.org/sample.jar!/sample.xul" > </HEAD> </HTML> 12.6.4. Receiving a Signed Application As shown in Figure 12-8, when Mozilla receives a JAR, it must check it for validity before displaying the contents. A public key in certs_mozdev.cacert must be used along with the digital signature to make sure that the contents are not tampered with and that the signature is valid. Figure 12-8. Receiving a signed application //FIXME did we loose content here? When you are developing a signed remote Mozilla application, clear a JAR's cache before trying to reload an updated version of it. Clearing the cache can be done most easily by restarting Mozilla. If you or your users do not do clear it, the consumer of the application will probably wind up with a blank screen. 12.7. Expanded Privileges in Mozilla While the security aspect of signed objects is nice, the ability to make remote JavaScript do just about anything is even better for web developers because it avoids the perceived complexity of languages like C++. Also, JavaScript, along with Perl and PHP, has always been a preferred language in the web environment. Knowing that Internet Explorer no longer has a huge advantage when it comes to remote browser-based applications is also nice, since JavaScript and XPCOM in Mozilla provide a framework very similar to ActiveX. They also provide web page scripting in which you can create and use components from a web page or web application. Table 12-1 shows the expanded privileges available to signed scripts. Signed applications are granted these privileges as a matter of course. Table 12-1. Expanded privileges available to signed scripts Privilege Purpose UniversalBrowserRead Reads sensitive browser data. This reading allows the script to pass the same origin check when reading from any document. UniversalBrowserWrite Modifies sensitive browser data. This modification allows the script to pass the same origin check when writing to any document. UniversalXPConnect Gives unrestricted access to browser APIs using XPConnect. UniversalPreferencesRead Reads preferences using the navigator.preference method. Privilege Purpose UniversalPreferencesWrite Allows you to set preferences using the navigator.preference method. CapabilityPreferencesAccess Allows you to read/set the preferences that define security policies, including which privileges are granted and denied to scripts. (You also need UniversalPreferencesRead/Write.) UniversalFileRead Handles window.open of file:// URLs. Makes the browser upload files from the user's hard drive by using <input type="file">. The JavaScript features require expanded privileges and the target used to access each feature. Unsigned scripts cannot do the following: • Use an about: format URL other than about:blank; requires UniversalBrowserRead. • Use the history object to find out what other sites the user visited or how many other sites the user visited in this session. Doing so requires UniversalBrowserRead. [...]... access to XPConnect as one of the security model's main boundaries Just as ActiveX makes COM available in IE, signing makes XPCOM available in remote Mozilla applications Given all that is possible in XPCOM, this chapter leaves what can be archived with remote Mozilla applications and XPConnect up to your imagination ... this method with captureEvents Close Unconditionally closes a browser window moveBy, moveTo Moves a window off of the screen • Open Creates a window smaller than 100 x 100 pixels or larger than the screen can accommodate by using innerWidth, Method / property Description innerHeight, outerWidth, and outerHeight • Places a window offscreen by using screenX and screenY • Creates a window without a titlebar . Chapter 12. Remote Applications- P4 Figure 12- 5. Downloading a certificate window After the certificate. available in remote Mozilla applications. Given all that is possible in XPCOM, this chapter leaves what can be archived with remote Mozilla applications