Closed xispa closed 1 year ago
Jordi Puiggené wrote at 2023-1-18 02:39 -0800:
A
TypeError: can't pickle cStringIO.StringO objects
is raised whenZPublisher
processes a request input record with a value that contains a character that needs to be tainted (e.g. "<") and when a record from "file" type has been processed previously.
Tainting is an old security feature for DTML: when form data or cookies are accessed implicitly via the request object, they are (HTML) quoted on DTML rendering if they contain unsafe characters.
The tainting logic is incredibly complex and your bug report reveals one of its holes. I have tried to streamline it in "https://github.com/zopefoundation/Zope/pull/648", but this is not yet merged (and might have the same problem you have observed).
Page templates no longer rely on tainting logic; they quote by default and unquoted rendering must be called for explicitly (and this hopefully is not done for things involving user input).
If you do not process untrusted user input with DTML objects, you could disable the tainting logic giving the envvar "ZOPE_DTML_REQUEST_AUTOQUOTE" e.g. the value "0". This should avoid the bug you have reported.
Note that Zope's management interface (--> "ZMI") partially still uses DTML.
Thus, if you disable tainting, you likely must restrict the use
of large parts of the ZMI to trusted users.
A good starting point would be to restrict the permission
View management screens
(or similarly spelled) to Manager
.
@xispa You could try the version from #1097.
Sure, let me try
Excellent! :confetti_ball: it works properly now. Thank you very much @d-maurer for your fast response, we really appreciate it!
BUG/PROBLEM REPORT / FEATURE REQUEST
A
TypeError: can't pickle cStringIO.StringO objects
is raised whenZPublisher
processes a request input record with a value that contains a character that needs to be tainted (e.g. "<") and when a record from "file" type has been processed previously.When a value from a record should be tainted,
ZPublisher
does it, but it also does adeepcopy
of the records processed earlier here: https://github.com/zopefoundation/Zope/blob/53d8f7e0d2e30a66984b1380dbe52c1fff764139/src/ZPublisher/HTTPRequest.py#L725-L726 . Thus, if one (or more) of these records processed earlier is from file type,deepcopy
cannot do the job and the following traceback arises:As a result, the base error screen from plone "We’re sorry, but there seems to be an error…" is rendered, but without any error or traceback information.
What I did:
Tried to submit a form made of the following:
What I expect to happen:
No traceback, records are processed correctly
What actually happened:
PDB session
What version of Python and Zope/Addons I am using: