About-This-Site

Explanatory Preface

Frankly, I'm reluctant to discuss the technical details of this site. The walls have ears and those ears can have bad hackers attached to them, as I've discovered to my regret. This site has been essential dead for the last two years as a result of hacker attacks and it has cost me untold hours of toil and trouble to get it going again in a fairly secure manner. So I'm not exactly enthusiastic about revealing details of how this site works.

On the other hand, why not. Everything connected with the site is read-only - nothing can be written to any file without user admin privileges. Consequently, this is more like a content rendering system than a content management system.

So have at it old buddies and good luck to you.

Background - The Problem with Python

A good result of the hacker attacks ( call it 'blowforward' perhaps ) is that it got me interested in Python again. I had a first round with Python around version 2.3 or so. It was a good language. lots of good features, but it was new and exotic with significant learning curves and, let's face it, does the world really another another computer language ? I don't think so.

In addition to being exotic, Python also had the disadvantage of being difficult deploy in a shared hosting environment. Most shared hosting limits Python to running as CGI, not a winner from a performance standpoint.

Another difficulty was the size and heavy-weightedness many python frameworks. I will emphasize that these framework are complete and powerful with many excellent features, but as of 3-4 years ago, most of them were not fully mature and production-ready. Anyway, running them as CGI was ( and still is ) pretty much out of the question.

A New Generation of Python Solutions

Several things have changed in recent years.

• Python micro-frameworks
• Improved support for Python in CGI shared hosting
• Faster hardware/lower user ratio per machine in shared hosting
• Improved performance of Python interpreter
• Wider acceptance of Python as a general purpose language

The combination of the factors above seem to make it possible to deploy a small but fairly full-featured Python site via CGI in a shared hosting environment. A shared account with 1) user permissions, 2) a simple browser-based file manager and 3) an FTP accout for cgi-bin is all that is needed to deploy a simple content rendering system - neither root permission nor secure shell (SSH ) are necessary. And best of all, no line commands. Once the basic installation and site configuration is set up, just FTP the sqlite file up to the server, check file permissions for read-only and run it. Publishing is that simple, at least for the public site.

The private, adminstrative site ( the publishing site ) would have to do the real work of content management and will be far more complex than the cgi-bin readonly system. [ I am currently using the SQLite Manager Plugin for Firefox as an adminstrative backend. Not a great solution, but it works ! ] Certainly, the administrative backend must have read-write permissions, which exposes it to all sorts of XSS and SQL injection attacks. Both Apache authentication and a user password would be required to access the admin directory, presumably in the cgi-bin directory, but it could also run as a stand-alone server on a local network or as a WSGI application on a python hosting site, such as Webfaction.

The question remains, is the scheme outlined above enough to guarantee a high level of hacker freedom for a simple blog/wiki site ? There may yet be some unanticipated problem or snag I'm not seeing at this point. As they say, it's under development.

More to come ... to CGI and Beyond

Tags:   BBcom   python