[mod_python] restricting access to certain variables usingmod_python.publisher

Graham Dumpleton wrote:

> The only workaround you would have in the short term is not to use
> an "index.py" file and always name it something different.

Always good advice. The only time I would even consider using a module 
named index.py would be as in Jan's example, where one might want to run 
an entire site with mod_python transparently.

> This is actually a security hole because any __auth__ stuff would
> be visible and thus people could work out login/passwd. This may
> require another security fix release of mod_python. :-(

No argument here, any information leak is a security hole and should be 
fixed. But, even with __auth__, there's no good reason to store login 
details in the module or anywhere within the DocumentRoot, for that matter.

> Jan Huelsbergen wrote ..
> 
>>The mod_python.publisher documentation states at
>>http://modpython.org/live/current/doc-html/hand-pub-alg-trav.html that
>>if
>>"Any of the traversed object's names begin with an underscore ("_")." 
>>they are not accsessable through the web, yet, when I put a 
>>_foo = 'bar'
>>in my index.py, http://my.site/_foo returns 'bar'. 
>>
>>Am I missinterpreting the documentation? 
>>How to protect a variable from outside access?

I've been creating all of my mod_python applications as packages that 
sit in a directory outside of the DocumentRoot. I use the PythonPath 
directive to append the directory to the module search path. Then I 
import enough of the package to bootstrap my published module, which 
might contain a single function that acts as a frontend to a dispatcher.

It might sound like a lot of work, but with good planning it can set a 
solid foundation for future projects, thus saving a *lot* of time in the 
long run. By using this approach, along with dotted notation imports, 
explicit restriction of *from imported objects with __all__, and 
enclosing almost everything in functions, I haven't been affected by any 
of the recent security issues, including this one.  You can even take 
this to an extreme and obfuscate your login details and imported names 
so that they would not be human readable or even grepped (haven't gone 
there, yet).

Example:

~/python/
     domain/
         __init__.py
         database.py
         html.py
         foo/
             __init__.py
             database.py
             form.py
         bar/
             __init.py
             database.py
             util.py

Then the published module might look like this:

  #foo.py
  import domain.foo

  def start(req):
      """
      Public interface to application backend.
      """
      return domain.foo.dispatch(req)

Nothing's exposed, lots of reusable code, provides for separation 
between modules, and results in excellent caching of imported modules 
and database connections. The only downside is that it makes you more 
dependent on a test environment, because it is sometimes necessary to 
restart apache to force a reload of imported modules that have been 
updated.