[Twisted-Python] Direct access to main server class

[Terry Jones]

Hi Andrew

>>>>> "Andrew" == Andrew Bennetts <andrew-twisted at puzzling.org> writes:
Andrew> I'm guessing a significant proportion of your code you want to
Andrew> test, probably the majority of it, has nothing directly to do with
Andrew> authentication or permissions.  Also, *unit* tests (as opposed to
Andrew> functional tests or integration tests or end-to-end tests or
Andrew> whatever other terms you prefer to use) test one thing at a time,
Andrew> so tests for this code shouldn't also be testing authentication.
Andrew> If *every* test has to authenticate, then you're just wasting
Andrew> effort: the tests run slower, there's more junk to step over in a
Andrew> debugger, and you gain no extra testing value by testing the exact
Andrew> same thing in 50 (or 500...) different tests.

That's why I'd use a setUp method: to log in to the server and store the
result for use in the unit tests.

Andrew> No, it's quite common, and sensible, for tests to go directly to
Andrew> the units (i.e.  objects and methods) they want to test, so that
Andrew> they test precisely what they should test.

Right, I can do that (and do do that in the to-be-converted code). I
suppose I'll just make myself an authenticated user object and then call
into internal methods.

It does make me wonder though, still. What if you're writing a Twisted app
that you intend to license for commercial companies to run on their
intranets: You install the Python source and presumably the unit test code
gets run at some point, and maybe remains on the server. Then you're
showing the world how to access the innards of your service without going
through the approved authentication. Same comments apply to simply putting
the code online and letting people see how to get in to any instance they
can get local (user) access to. What can be done to prevent this? The most
obvious thing seems to be to verify the uid of the process trying to create
an authenticated user, and have both your unit tests and twistd run under
this uid.  If you don't do something about this, a normal user on the
system can simply import your module, create an instance, and start making
method calls (possibly unsuccessfully, due to file system permissions on
databases, etc). Maybe they wont get far, but it's an issue: especially if
the system has been built to allow this, and the unit tests show precisely
how to pull it off.

Thanks again,
Terry