[Twisted-Python] Direct access to main server class
terry at jon.es
Tue Aug 29 03:57:36 EDT 2006
>>>>> "glyph" == glyph <glyph at divmod.com> writes:
glyph> If you think you can hide Python code by compiling it to bytecodes,
glyph> have a look at http://www.crazy-compilers.com/decompyle/ -- that
glyph> should quickly disabuse you of that notion.
No, I have no intention of doing that - rather I assume the opposite (that
code and tests will all be available), that's what I thought I was saying.
glyph> Moreover, any security scheme that relies, in any way, upon the fact
glyph> that your code is hidden is broken by design. From wikipedia:
glyph> "computer science professors consider security through obscurity so
glyph> obviously wrong that the matter doesn't need proof or study".
Yes, I agree that's it's almost always an error (and those that choose it
reflexively are also particularly prone to the attendant false sense of
security. One would hope that some form of Darwinian selection might kick
in, but it never does).
glyph> However, even disregarding that, _some_ code in your system is
glyph> instantiating authenticated users and calling methods on them.
glyph> Assuming that your code is packaged and distributed (tests included,
glyph> so as to make testing of deployments easier), anyone who can read
glyph> the tests can read the rest of the code, and discover the same
Right, that's what I was saying.
glyph> So, I disagree in the strongest possible terms: it *isn't* an issue,
I don't understand how the above sentence follows from the one before (and
no, I'm not trolling either!).
glyph> and nobody should ever consider it as such when writing tests. The
glyph> correct way to write unit tests is one unit at a time, and it should
glyph> not be polluted by misguided security concerns.
glyph> Apologies if this sounds too harsh. I'm not just trolling, I
glyph> promise :). We have a lot of tests in the Twisted suite which bend
glyph> over backwards to instantiate things through obtuse
glyph> higher-than-unit-level interfaces (which often aren't really
glyph> themselves public), rather than testing functionality directly.
glyph> These tests are all overcomplex, error prone, and generally contain
glyph> race conditions and fail intermittently for unrelated reasons.
OK, I think we have the same aim: I'm trying to NOT write obtuse and
complex tests. That's why I was originally asking if there's an easy way to
make tests go through the front door (via twisted.cred) to get something
they can start making calls on. I wanted to do that precisely to _avoid_
bending over backwards etc. I have a couple of hundred unit tests (a very
small number, I know), of which only a few are more than about 4 lines. I'm
trying to keep it that way.
I have the feeling that my original mail should probably have been written
more clearly. And it's time for a coffee...
More information about the Twisted-Python