[Zope] Re: Error -> A TaintedString cannot be pickled

Dieter Maurer dieter@handshake.de
Fri, 18 Apr 2003 21:46:27 +0200


Jamie Heilman wrote at 2003-4-17 13:38 -0700:
 > Dieter Maurer wrote:
 > > Jamie Heilman wrote at 2003-4-16 12:53 -0700:
 > >  > Personally I think REQUEST.get is a hallmark of horrible design anyway.
 > > Why do you think so?
 > 
 > It flattens namespaces that don't have the same characteristics.
 > 
 > This tends to catch programmers off guard and introduce bugs.  If you
 > have an 8k header limit defined in your HTTP server along with a 1M
 > POST limit and then you use REQUEST.get() to grab a cookie value
 > without taking into account that it could be 1M in length before you
 > go to process it, bad things can happen.  "This is one of the
 > instances where you should use the exact dictionary," you say.

Indeed. When you know the value must come in a cookie your would
say so.

 > Well
 > sure, but what do you do when you've got interfaces built around
 > REQUEST.get() magic that don't let you choose?  Case in point, a
 > RAMCache's aggregateIndex function blindly REQUEST.get()'s a list of
 > manager defined variables.  If you aren't careful this has some really
 > really shitty security implications.

Everything is REQUEST has security implications.

   With the exception of some elements in "REQUEST.environ", everything
   can be forged.

Beside this, the application can know the expected interface
(the control variable names used in respective forms) and
form variables take preceedence over cookies (that are not local).
Thus, cookies do not present a problem.

 > It also changes the trust characteristics of the variables.  A
 > key-value pair provided by the server that the request has no inate
 > ability to change, normally trustworthy, is degraded by getting placed
 > into the grab order of REQUEST.get().

At least the documentation says that "REQUEST.environ" lookup
takes preceedence before other sources. "environ" is
the source for the server defined keys you mention.

 > ....
 > In short, if you want a function to do variable aggregation, thats OK,
 > but its my believe that function shouldn't be sold to the masses as
 > the 99% solution to all their data gathering needs; it should be the
 > exception rather than the rule, it should offer a flexible way to
 > include, exclude, and re-order the lookup rules on the fly, and there
 > should be no default order--the order should be a mandatory argument,
 > thus forcing the programmer into thinking about which namespaces are
 > truely pertinent.

Acquisition is a much more drastic "namespace flattening" (as
you call it) than the harmless merging of 4 individual dictionaries
in REQUEST.

I know, it can be dangerous but nevertheless I am very happy
that it is is there and makes lots of my daily tasks much
easier.

I have much more trust in programmers than you seem to have.
We are developping internet applications and (hopefully) not
nuclear power plant controls, airflight control systems
or such high rish applications. Therefore, ease of development
is a valuable factor.


Dieter