| Tclets run in a safe interpreter that is set up with the safe base facilities described on page 284. This limits a Tclet to a display-only application. To do something more interesting, you have to grant the Tclet more privilege. The extra functions are bundled together into a security policy, which is implemented as a set of command aliases. Unlike a Java applet, a Tclet can choose from different security policies. A few standard security policies are distributed with the plugin, and these are described below. You can also create custom security policies to support intranet applications. You can even choose to grant certain Tclets the full power of Tcl/Tk. The policy command is used to request a security policy: policy name The policies that are part of the standard plugin distribution are described below. The home, inside, and outside policies all provide limited network access. They differ in what set of hosts are accessible. The default trust configuration lets any Tclet request the home, inside or outside policy. home. This provides a socket and fconfigure command that are limited to connecting to the host from which the Tclet was downloaded. You can specify an empty string for the host argument to socket to connect back to the home host. This policy also supports open and file delete that are similar to the Tempfile policy shown in Example 19-9 on page 288. This provides limited local storage that is inside a directory that is, by default, private to the Tclet. Files in the private directory persist after the Tclet exits, so it can maintain long term state. Tclets from the same server can share the directory by putting the same prefix=partialurl argument in their EMBED tag. The partialurl must be a prefix of the Tclet's URL. Finally, the home policy automatically provides a browser package that is described later. inside. This is just like the home policy, except the site administrator controls a table of hosts and ports to which untrusted slaves can connect with socket. A similar set of tables control what URLs can be accessed with the browser package. This is similar to the Safesock policy is shown in Example 19-8 on page 286. The set of hosts is supposed to be inside the firewall. The local file storage used by this policy is distinct from that used by the home and outside policies. This is true even if Tclets try to share by using the prefix=partialurl parameter. outside. This is just like the home and inside policies, except that the set of hosts is configured to be outside the firewall. The local file storage used by this policy is distinct from that used by the home and inside policies. trusted. This policy restores all features of Tcl and Tk. This policy lets you launch all your Tcl and Tk applications from the Web browser. The default trust map settings do not allow this for any Tclet. The trust map configuration is described later. javascript. This policy provides a superset of the browser package that lets you invoke arbitrary Javascript and to write HTML directly to frames. This does not have the limited socket or temporary file access that the home, inside, and outside policies have. However, the javascript policy places no restrictions on the URLs you can fetch, plus it lets Tclets execute Javascript, which may have its own security risks. The default trust map settings do not allow this for any Tclet.
The Browser Package The browser package is bundled with several of the security policies. It makes many features of the Web browser accessible to Tclets. They can fetch URLs and display HTML in frames. However, the browser package has some risks associated with it. HTTP requests can be used to transmit information, so a Tclet using the policy could leak sensitive information if it can fetch a URL outside the firewall. To avoid information leakage, the inside, outside, and home policies restrict the URL that can be fetched with browser::getURL. Table 20-3 lists the aliases defined by the browser package. Table 20-3. Aliases defined by the browser package.| browser::status string | Display string in the browser status window. | | browser::getURL url ?timeout? ?newcallback? ?writecallback? ?endcallback? | Fetches url, if allowed by the security policy. The callbacks occur before, during, and after the url data is returned. | | browser::displayURL url frame | Causes the browser to display url in frame. | | browser::getForm url data ?raw? ?timeout? ?newcallback? ?writecallback? ?endcallback? | Posts data to url. The callbacks are the same as for browser::getURL. If raw is 0, then data is a name value list that gets encoded automatically. Otherwise it is assume to be encoded already. | | browser::displayForm url frame data ?raw? | Posts data to url and displays the result in frame. The raw argument is the same as in browser::getForm. |
The browser::getURL function uses the browser's built-in functions, so it understands proxies and supports ftp:, http:, and file: urls. Unfortunately, the browser::getURL interface is different than the http::geturl interface. It uses a more complex callback scheme that is due to the nature of the browser's built-in functions. If you do not specify any callbacks, then the call blocks until all the data is received, and then that data is returned. The callback functions are described in Table 20-4. Table 20-4. The browser::getURL callbacks.| newcallback name stream url mimetype datemodified size | This is called when data starts to arrive from url. The name identifies the requesting Tclet, and the stream identifies the connection. The mimetype, datemodified, and size parameters are attributes of the returned data. | | writecallback name stream size data | This is called when size bytes of data arrive for Tcllet name over stream. | | endcallback name stream reason data | This is called when the request has completed, although there may be some final bytes in data. The reason is one of: EOF, NETWOR_ERROR, USER_BREAK, or TIMEOUT. |
|
