- View page fields (CGI server to client): To direct the next script’s behavior, the
password is embedded in the view page itself as HTML hidden input fields, en-
crypted or obfuscated, and HTML escaped. - Delete message (client to CGI server to POP server): Finally, the password is again
passed from client to CGI server, this time as hidden form field values; the CGI
script decodes it and passes it to the POP server to delete.
Along the way, scripts have passed the password between pages as both a URL query
parameter and an HTML hidden input field; either way, they have always passed its
encrypted or obfuscated string and have never passed an unencoded password and
username together in any transaction. Upon a Delete request, the password must be
decoded here using the secret module before passing it to the POP server. If the script
can access the POP server again and delete the selected message, another confirmation
page appears, as shown in Figure 16-19 (there is currently no verification for the delete,
so be careful).
Figure 16-19. PyMailCGI delete confirmation
One subtlety for replies and forwards: the onViewPageAction mail action script builds
up a >-quoted representation of the original message, with original “From:”, “To:”, and
“Date:” header lines prepended to the mail’s original text. Notice, though, that the
original message’s headers are fetched from the CGI form input, not by reparsing the
original mail (the mail is not readily available at this point). In other words, the script
gets mail header values from the form input fields of the view page. Because there is no
“Date” field on the view page, the original message’s date is also passed along to the
action script as a hidden input field to avoid reloading the message. Try tracing through
the code in this chapter’s listings ahead to see whether you can follow dates from page
to page.
Processing Fetched Mail| 1271