Webware for Python

Chuck Esterbrook wrote:

> I think Geoff touched on this earlier, but I don't remember how explicit he
> was or how many people connect it with the recent to change to how the
> WebKit app server imports servlets.
>
> This applies to Webware CVS only. The gist is this:
>
>  From within a directory, you can import servlet classes that are in the
> parent directory.

This sounds like acquisition in training.

Based on my experience with Zope and acquisition, I would say: There are times when it saves a little effort (thought and planning) in the short run, but from a security perspective, it make the site a nightmare to verify.  Zope has a lot of code that deals with making sure that an object has the proper security attributes to be used in a given context.  Webware has no such support (and probably will not for a while -- Zope, with several paid full-time developers, is still trying on getting it right after two years of wide public exposure.)

My recommendation is exactly what Chuck recommended to me a few months ago, when I complained about security and acquisition:  Unless a file represents a concrete document (SitePage is an abstract document), keep it out of the document tree. Put SitePage.py in a lib/ directory in a MySite/ package, then say:

    from MySite.SitePage import SitePage

The grey hair you save will be your own.

Of course, if you just want rapid deployment, and don't have sensitive content/code, this may be just the ticket.  YMMV.

    my $0.02
    -- Terrel

(Try http://example.org/webkit/MySite/SitePage.py~ after a "quick fix".)

At 01:06 PM 3/26/2001 -0500, Terrel Shumway wrote:
>Of course, if you just want rapid deployment, and don't have sensitive 
>content/code, this may be just the ticket.  YMMV.

Yes, I think it depends on how paranoid you feel you have to be for a 
particular site.

Although, regardless of how much care you take under the hood, you still 
need a test suite that tries to break your security (and hopefully that 
test suite is automated).


>     my $0.02
>     -- Terrel
>
>(Try http://example.org/webkit/MySite/SitePage.py~ after a "quick fix".)

I would hope that a production site would have such files stripped out or 
at least reported, again preferably by a script that runs automatically 
(via cron).

And ExtensionsToServe will address this in 1.0.

-Chuck

Chuck Esterbrook wrote:

> >(Try http://example.org/webkit/MySite/SitePage.py~ after a "quick fix".)
>
> I would hope that a production site would have such files stripped out or
> at least reported, again preferably by a script that runs automatically
> (via cron).
>

Exactly: security in depth.  (BTW, there should be no "quick fix" for a high-paranoia production site.)

> And ExtensionsToServe will address this in 1.0.

That would certainly reduce the problem.  Will ExtensionsToServe return "404 Not Found" if the client sends the full name as suggested above, or will it only kick in to generate extensions if the specified file does not exist?

At 03:59 PM 3/26/2001 -0500, Terrel Shumway wrote:
>That would certainly reduce the problem.  Will ExtensionsToServe return 
>"404 Not Found" if the client sends the full name as suggested above, or 
>will it only kick in to generate extensions if the specified file does not 
>exist?

I don't even understand what "kick in to generate extensions..." means.

My thought for ExtensionsToServe was to generate 404 for any request whose 
server side path did NOT have an extension found in ExtensionsToServe.

After that check clears, it's business as usual.

-Chuck