📄 ch15.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<!-- This document was created from RTF source by rtftohtml version 3.0.1 -->
<META NAME="GENERATOR" Content="Symantec Visual Page 1.0">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<TITLE>Without a title - Title</TITLE>
</HEAD>
<BODY BACKGROUND="r2harch.gif" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/r2harch.gif" TEXT="#000000" BGCOLOR="#FFFFFF">
<H2 ALIGN="CENTER"><A HREF="ch14.htm" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/ch14.htm"><IMG SRC="blanprev.gif" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/blanprev.gif" WIDTH="37" HEIGHT="37"
ALIGN="BOTTOM" BORDER="2"></A><A HREF="index-1.htm" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/index-1.htm"><IMG SRC="blantoc.gif" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/blantoc.gif" WIDTH="42"
HEIGHT="37" ALIGN="BOTTOM" BORDER="2"></A><A HREF="ch16.htm" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/ch16.htm"><IMG SRC="blannext.gif" tppabs="http://210.32.137.15/ebook/Web%20Programming%20with%20Perl%205/blannext.gif"
WIDTH="45" HEIGHT="37" ALIGN="BOTTOM" BORDER="2"></A><BR>
<BR>
<BR>
<FONT COLOR="#0000AA">15</FONT><BR>
<A NAME="Heading1"></A><FONT COLOR="#000077">Client-Side Perl<BR>
</FONT>
<HR>
</H2>
<UL>
<LI><A HREF="#Heading1">Client-Side Perl</A>
<UL>
<LI><A HREF="#Heading4">Embedded Perl Interpreter in a <BR>
Web Browser</A>
<LI><A HREF="#Heading6">Executing Perl as a Helper Application</A>
<LI><A HREF="#Heading7">Listing 15.1. HelperAppPerl.</A>
<LI><A HREF="#Heading8">PenguinA New Paradigm in Remote Execution</A>
<LI><A HREF="#Heading9">Parsing Netscape History Files</A>
<LI><A HREF="#Heading11">Summary</A>
</UL>
</UL>
<P>
<HR>
</P>
<UL>
<LI>Embedded Perl Interpreter in a Web Browser
<P>
<LI>Executing Perl as a Helper Application
<P>
<LI>Penguin--A New Paradigm in Remote Execution
<P>
<LI>Parsing Netscape History Files
</UL>
<P>In this chapter, we're going to take a look at how to use Perl on the client,
or browser, side of the Web connection. There are several useful possibilities. As
with other chapters, we'll try to focus on the techniques that involve existing Perl5
modules and extensions.</P>
<P>Probably the most interesting (and dangerous) of the possibilities for using Perl
on the client side is to use it to process a given URL's contents directly as a script.
You can do this in one of two ways. You can associate a given MIME type/extension
with the Perl application and have Perl start and process the URL's contents when
you receive a URL of this type, or, more interestingly, you can embed the Perl application,
possibly as a Netscape plug-in, into the browser and execute the contents of the
URL directly, sending the output back to the Netscape window.
<DL>
<DT></DT>
</DL>
<H3 ALIGN="CENTER">
<HR WIDTH="83%">
<BR>
<FONT COLOR="#000077">NOTE:</FONT></H3>
<BLOCKQUOTE>
<P>We need to point out that at the time this book was written, there was only a
single example of a Netscape plug-in that invokes Perl. We're going to focus on the
possibilities with regard to plug-ins and embedded Perl in this chapter, rather than
on what is already available.<BR>
<HR>
</BLOCKQUOTE>
<P>Security becomes a very big issue when you start to consider using Perl at your
end to process any given URL's contents directly as a program. There are a number
of risks to you, as the client, when executing arbitrary code from the Net. Just
as with Java or JavaScript, or any other interpreter used from the client side, a
number of precautions need to be taken. We'll try to cover these in some detail in
this chapter.
<DL>
<DT></DT>
</DL>
<H3 ALIGN="CENTER">
<HR WIDTH="83%">
<BR>
<FONT COLOR="#000077">CAUTION:</FONT></H3>
<BLOCKQUOTE>
<P>Some or all of what follows may be regarded as highly controversial, or even forbidden,
from a security standpoint. It's important to emphasize that you can't be too careful
when executing arbitrary code, programs, applets, or even macros directly from the
Net in any language. Don't hesitate to ask your system administrator if you have
any questions or concerns about using any programming language, including Perl, on
the client side, especially if you're on a secure or firewalled site. Proceed with
caution. Buyer beware! Caveat scriptor! No warranty is implied or given, and so on.<BR>
<HR>
</BLOCKQUOTE>
<H3 ALIGN="CENTER"><A NAME="Heading4"></A><FONT COLOR="#000077">Embedded Perl Interpreter
in a <BR>
Web Browser<A NAME="Heading5"></A></FONT></H3>
<P>At the time of this writing, there is only one Web browser that has the functionality
to support an embedded Perl interpreter. That browser is Netscape, through its plug-in
mechanism. There has been a rumor that the Microsoft browser will also support plug-ins
soon, but we did not investigate this.</P>
<P>As we've already mentioned, at the time of this writing, there is only one example
of a Netscape plug-in that invokes Perl. It does not actually embed the Perl interpreter
into the plug-in, but rather it uses UNIX pipes to communicate with the Perl executable.
Before we take a look at it, let's consider the list of potential components of an
embedded mechanism in a browser. There are a number of features that definitely should
be part of any future Perl plug-in, and others that certainly might be nice to have
in a fully implemented plug-in, once someone finally takes the time and expertise
to write it and release it.
<UL>
<LI>Secure Runtime Environment: Above all else, the Perl plug-in needs to be secure.
If it's going to be released to the public, especially, it should be configured to
be as secure and restrictive in its default capabilities as possible. The Safe module,
which we looked at in some detail in Chapter 3, "Security on the Web,"
gives us the capability to completely mask given operations considered to be insecure,
to keep them from ever being executed by the Perl interpreter. Any Perl plug-in should
use the Safe/Opcode modules, by default. The Perl plug-in we'll look at later certainly
does.
<P>
<LI>Encryption/Signatures: You might want to assure that the code you're executing
has come from a source you trust, via your PGP keyring, for instance. If the decoded
and/or signature-verified code is from a known, trusted source, you could execute
it straight away without too many worries. If it isn't, then you'd (hopefully) want
to inspect the code carefully and understand what it will do before executing it.
The PGP module we looked at in Chapter 3 might be a viable means for decrypting or
verifying the signature on a chunk of Perl code before executing it.
<P>
<LI>Cross-Platform Compatibility: One of the nicest things about the Java and JavaScript
languages is that their applets, or scripts, are guaranteed to run on any platform
that has the embedded Java within the Netscape (or Microsoft) browser. When using
Perl, on the other hand, there's no way to ensure that a given script will run on
any platform. There are commands, modules, and other capabilities that are platform-dependent
in Perl. The capability to fork() or exec() a process, for instance, is pretty much
limited to the UNIX platform. Because Perl is so UNIX-centric, many of the libraries
and modules contain platform-specific code. There is a general trend away from this
tendency, but it's a slow and sometimes painful one. Other times, it's just not possible
to make a given program or module compatible with all of the architectures that can
run Perl. The core functionality of Perl is usually available to any script, however.
With this in mind, you could design the scripts to be served to clients appropriately.
Alternatively, you could force the client to have the Mozilla-UNIX identifier before
serving the script to it if there were known incompatibilities with other architectures.
Finally, if you really need to get something like a module or library to work on
an unsupported or untested architecture, you could always port the code to that architecture.
Be sure to let the author know and submit changes you had to make to get the module
working, and so on.
<P>
<LI>Byte-Code Interpretation: Byte-Code is a form of a Perl program or script that
has been precompiled. When bytecode is sent over the Net as an executable, it's called
an applet in the Java world. There are several advantages to running bytecode as
opposed to parsing and compiling a text file. The first, and probably the most important
from a shared-code standpoint, is that it's much more difficult (but not impossible)
to change a bytecode program once it's been created than it is to change a given
textfile script. This adds some assurance to the client that what they receive and
execute is indeed what you intended for them to receive as the server. The second
advantage is speed. The bytecode program is in its final form, already parsed and
reduced to an opcode tree. Thus, when you feed it to Perl, Perl can load and execute
it directly, reducing the time to get a result. Finally, there's an enhancement in
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -