Rolling your own encryptor
As is, PyMailCGI avoids ever passing the POP account username and password across
the Net together in a single transaction, unless the password is encrypted or obfuscated
according to the module secret.py on the server. This module can be different every-
where PyMailCGI is installed, and it can be uploaded anew in the future—encrypted
passwords aren’t persistent and live only for the duration of one mail-processing in-
teraction session. Provided you don’t publish your encryption code or its private keys,
your data will be as secure as the custom encryption module you provide on your own
server.
If you wish to use this system on the general Internet, you’ll want to tailor this code.
Ideally, you’ll install PyCrypto and change the private key string. Barring that, replace
Example 16-13 with a custom encryption coding scheme of your own or deploy one of
the general techniques mentioned earlier, such as an HTTPS-capable web server. In
any event, this software makes no guarantees; the security of your password is ulti-
mately up to you to ensure.
For additional information on security tools and techniques, search the Web and con-
sult books geared exclusively toward web programming techniques. As this system is
a prototype at large, security is just one of a handful of limitations which would have
to be more fully addressed in a robust production-grade version.
Because the encryption schemes used by PyMailCGI are reversible, it is
possible to reconstruct my email account’s password if you happen to
see its encrypted form in a screenshot, unless the private key listed in
secret.py was different when the tests shown were run. To sidestep this
issue, the email account used in all of this book’s examples is temporary
and will be deleted by the time you read these words. Please use an email
account of your own to test-drive the system.Common Utilities Module
Finally, the file commonhtml.py in Example 16-14 is the Grand Central Station of this
application—its code is used and reused by just about every other file in the system.
Most of it is self-explanatory, and we’ve already met most of its core idea earlier, in
conjunction with the CGI scripts that use it.
I haven’t talked about its debugging support, though. Notice that this module assigns
sys.stderr to sys.stdout, in an attempt to force the text of Python error messages to
show up in the client’s browser (remember, uncaught exceptions print details to
sys.stderr). That works sometimes in PyMailCGI, but not always—the error text
shows up in a web page only if a page_header call has already printed a response pre-
amble. If you want to see all error messages, make sure you call page_header (or print
Content-type: lines manually) before any other processing.
1286 | Chapter 16: The PyMailCGI Server