Section 18.5. Grail: A Python-Based Web Browser

18.5. Grail: A Python-Based Web Browser

I briefly mentioned the Grail browser near the start of Chapter 13. Many of Python's Internet tools date back to and reuse the work that went into Grail, a full-blown Internet web browser that:

Is written entirely in Python
Uses the Tkinter GUI API to implement its user interface and render pages
Downloads and runs Python/Tkinter scripts as client-side applets

As mentioned earlier, Grail was something of a proof of concept for using Python to code large-scale Internet applications. It implements all the usual Internet protocols and works much like common browsers such as Netscape and Internet Explorer. Grail pages are implemented with the Tkinter text widgets that we met in Part III of this book.

More interestingly, the Grail browser allows applets to be written in Python. Grail applets are simply bits of Python code that live on a server but are run on a client. If an HTML document references a Python class and file that live on a server machine, Grail automatically downloads the Python code over a socket and runs it on the client machine, passing it information about the browser's user interface. The downloaded Python code may use the passed-in browser context information to customize the user interface, add new kinds of widgets to it, and perform arbitrary client-side processing on the local machine. Roughly speaking, Python applets in Grail serve the same purposes as Java applets in common Internet browsers: they perform client-side tasks that are too complex or slow to implement with other technologies such as server-side CGI scripts and generated HTML.

18.5.1. A Simple Grail Applet Example

Writing Grail applets is remarkably straightforward. In fact, applets are really just Python/Tkinter programs; with a few exceptions, they don't need to "know" about Grail at all. Let's look at a short example; the code in Example 18-7 simply adds a button to the browser, which changes its appearance each time it's pressed (its bitmap is reconfigured in the button callback handler).

There are two components to this page definition: an HTML file and the Python applet code it references. As usual, the grail.html HTML file that follows describes how to format the web page when the HTML's URL address is selected in a browser. But here, the APP tag also specifies a Python applet (class) to be run by the browser. By default, the Python module is assumed to have the same name as the class and must be stored in the same location (URL directory) as the HTML file that references it. Additional APP tag options can override the applet's default location.

Example 18-7. PP3E\Internet\Other\Grail\grail.html

 <HEAD> <TITLE>Grail Applet Test Page</TITLE> </HEAD> <BODY> <H1>Test an Applet Here!</H1> Click this button! <APP CLASS=Question> </BODY>

The applet file referenced by the HTML is a Python script that adds widgets to the Tkinter-based Grail browser. Applets are simply classes in Python modules. When the APP tag is encountered in the HTML, the Grail browser downloads the Question.py source code module (Example 18-8) and makes an instance of its Question class, passing in the browser widget as the master (parent). The master is the hook that lets applets attach new widgets to the browser itself; applets extend the GUI constructed by the HTML in this way.

Example 18-8. PP3E\Internet\Other\Grail\Question.py

 # Python applet file: Question.py # in the same location (URL) as the HTML file # that references it; adds widgets to browser; from Tkinter import * class Question:                            # run by Grail?     def _ _init_ _(self, parent):          # parent=browser         self.button = Button(parent,                              bitmap='question',                              command=self.action)         self.button.pack( )     def action(self):         if self.button['bitmap'] == 'question':             self.button.config(bitmap='questhead')         else:             self.button.config(bitmap='question') if _ _name_ _ == '_ _main_ _':     root = Tk( )                    # run standalone?     button = Question(root)          # parent=Tk: top-level     root.mainloop( )

Notice that nothing in this class is Grail or Internet specific; in fact, it can be run (and tested) standalone as a Python/Tkinter programtry it. When run by Grail (with the browser/page object as the master), the button appears as part of the web page instead. Either way, its bitmap changes on each press.

In effect, Grail applets are simply Python modules that are linked into HTML pages by using the APP tag. The Grail browser downloads the source code identified by an APP tag and runs it locally on the client during the process of creating the new page. New widgets added to the page (like the button here) may run Python callbacks on the client later, when activated by the user.

Applets interact with users by creating one or more arbitrary Tkinter widgets. Of course, the previous example is artificial, but notice that the button's callback handler could do anything we can program in Python: updating persistent information, popping up new user interaction dialogs, calling C extensions, using Python's networking tools, and so on.

Having said all that, I should add that Grail is no longer formally maintained, and it is now used primarily for research purposes (Guido never intended for Grail to put Netscape or Microsoft out of business). You can still find the Grail for free with a web search, and you can use it for surfing the Web or experimenting with alternative web browser concepts, but it is not the active project it was a few years ago.

If you want to code web browser applets in Python, the more common approach today is to use the Jython system described previously. Embedding Python code in HTML with the Active Scripting extension described later in this chapter is yet another way to integrate client-side code.

The Missing rexec Section

In the second edition of this book, this chapter included a section on the rexec restricted execution mode module in the standard library. This module allowed for safe execution of program code obtained from unknown sources.

For instance, expressions input in GUIs and code typed into web form fields cannot generally be given access to all machine resourcesa malicious user might use this as a way to impact your computer. By default, such code has only as much machine access as the permissions of the running Python process allow. The rexec module went beyond this, to make system libraries and system-related functions such as open restricted; Python code could essentially approve or disapprove access to such tools on a case-by-case basis.

Since the second edition of this book, the rexec module (and a relative, bastion) have been shown to have vulnerabilities. In fact, the Python 2.4 manuals claim that they have been removed in Python 2.3. These modules may still be imported in 2.4, but they raise an exception whenever their code is used, with a message that they are unsafe in 2.2 and 2.3. This makes them unusable.

Unfortunately, there is still no replacement for rexec at the time of this writing. It seems likely that rexec will either be replaced or be upgraded in the future; see Python documentation for developments on this front.

As mentioned often in this text, for now be sure to convert strings to numbers with limited tools such as int and float, instead of with tools that treat strings as program code, such as eval and exec. If this is not sufficient, untrusted code must generally be run in a restricted process, and possibly be scanned for unsafe constructs. Security is a complex issue; in fact, one clever reader also pointed out a vulnerability in an example in this deleted section!

See also the discussion of Windows Active Scripting later in this chapterbecause that support depended on rexec to run code embedded in web pages in a secure environment, it no longer is provided. Without language support for a secure sandbox, embedded code would have complete access to the underlying client machine. Until a rexec replacement emerges, Active Scripting has been withdrawn. This may be a temporary state, but it is impossible to predict.