"Paul A. Rombouts" <[EMAIL PROTECTED]> writes in his 1st message:
> I've implemented an extension to WWWOFFLE that allows WWWOFFLE to execute local > files and use its output instead of its contents. The executed program receives > information from WWWOFFLE in the form of environment variables, CGI-style. The patch that was included with your second e-mail shows a much more complete implementation than the one that you sent me at the end of last year. It is now (almost) a complete implementation of the CGI specification rather than a special format interface. I have previously held-off from implementing a CGI interface because I didn't see the need for them (although people did ask) and it is a potential security problem. Bad CGI programs cause many of the security problems with web-servers, disallowing them removes immediately the potential problems. Before including this patch into WWWOFFLE we need to consider the security implications. For example should the running of scripts be disallowed if the server is running as root? > The first is to bypass so called "interstitial" or intermediary ads. > For instance, http://www.msnbc.com/news/TECH_Front.asp > > redirects you to > > >http://www.msnbc.com/ads/trans/taDisplay.asp?realURL=/news/TECH_Front.asp&qs=&title=MSNBC+Technology&adf=nbctes&clik=redir > > This is a page with a large ad, which also contains a link to the real > content you wanted: > > http://www.msnbc.com/news/TECH_Front.asp?ta=y > > With my extension to WWWOFFLE, I put the following in the DonGet section of > the configuration file: > > http://*.com/ads/* > <http://*msnbc.com/ads/trans/taDisplay.asp?*realURL*> replacement = >/local/bin/msnbc_redirector Unfortunately this will only work when you are browsing online and will not work if you request the original page when offline. This is because WWWOFFLE will ignore any requests to fetch a page from the local WWWOFFLE server when it is fetching (and anyway it doesn't use the DontGet replacement option when fetching). "Paul A. Rombouts" <[EMAIL PROTECTED]> writes in his 2nd message: > I've included a patch file with this message. To make the patch, I have > extracted only those changes I made to the source that are necessary to execute > scripts. I've tested the patch by patching the original wwwoffle-2.6d source > code with it and compiling the result, but I haven't tested the resulting > executable. The patch seems to be a combination of two changes, only the change to the file messages.l is needed (I think). The other changes seem unnecessary and parts are not acceptable for WWWOFFLE (the stpcpy() function is not portable). The changes to messages.l also need to remove the use of that particular function. > To execute a script under this extension, you must place it somewhere in the > /var/spool/wwwoffle/html/local directory and give the file execution permissions > (including execution by others). You must make sure that no other files in this > directory have (unintentional) execution permissions, or you could get some > strange results. (For this reason I will probably limit the scope of my wwwoffle > extension to a special directory in the future.) Files with permissions ??? ??? ??x will be run using this extension, files with permissions ??- ??- r?- will be served up as plain text files and any others will give an error. This again has a portability problem with the cygwin environment where DOS permissions are used and there is no execute bit. Perhaps naming the files *.cgi would help. > The following information is passed on to the script: > One argument containing the url that was originally requested. (This is still a > leftover from the first crude version I made, in the future I will probably put > this information in the environment variable REQUEST_URI.) > The rest of the information is passed in environment variables. This seems to be an almost complete implementation of the CGI environment variable passing specification as defined at http://hoohoo.ncsa.uiuc.edu/cgi/env.html. It is missing the general SERVER_SOFTWARE, SERVER_NAME and GATEWAY_INTERFACE variables although your Perl module tries (and fails) to re-create the first two of these. There are also a few more request specific variables that could be set if you were going for the full set. > The output of the script must be a complete HTTP response, including headers. As > an example I've included a small perl module with subroutines to generate > responses, but you will probably want to adapt these before using them. If a full CGI implementation is used then the Perl CGI module can be used to get the environment variables and generate the reply headers. > If your script detects an error, it should either print an HTML error message > and exit with status 0 or 1, or it should print nothing to stdout and exit with > status greater than 1. If a script terminates with non-zero exit status, this > will be noted in your logfile(s). I think that with completion of the CGI specification, security considerations, and sorting out the portability issues this could become a standard part of WWWOFFLE. I think that it is too late now for version 2.7, but for version 2.7a I would accept a suitable patch. -- Andrew. ---------------------------------------------------------------------- Andrew M. Bishop [EMAIL PROTECTED] http://www.gedanken.demon.co.uk/ WWWOFFLE users page: http://www.gedanken.demon.co.uk/wwwoffle/version-2.6/user.html
