search

plone / plone.protect

HTTP protection utilities for the Plone CMS
https://pypi.org/project/plone.protect/
7 stars 8 forks source link

Improper and useless error reporting #71

Open zopyx opened 6 years ago

zopyx commented 6 years ago

This is a followup of

https://github.com/plone/Products.CMFPlone/issues/2316

The given traceback is complete irrelevant and has nothing to do with the real underlaying (and still unclear) problem.

It is nearly impossible to debug or read from the traceback where the exact problem is - to be precise: where the offending code is that would cause a CSRF violation here.

davisagli commented 6 years ago

Writes without a CSRF authenticator are indeed hard to debug because the problem is detected at the end of the transaction but occurred earlier when some object was modified. I don't see how we would improve this without monkey-patching the ZODB to do checks immediately when modified objects are registered with the connection.

lukasgraf commented 6 years ago

FYI, I've written a view that does exactly that (monkey patch Connection.register() to track changes) a while back in our own application. (Accompanying blog post here).

And it still can be very difficult to track down the culprit if you have multiple writes to multiple objects in the same transaction: Even if you were to track all the call stacks that cause an object to be registered, you still can't be sure which one contains the offending write. As a human. Let alone as a piece of code that's supposed to present to the human the exact traceback for the offending write.

djay commented 6 years ago

It would be very very useful if this could be part of plone.protect itself and shipped with plone itself as some kind of debug only mode feature. Maybe enabled by a env variable?

On 14 Mar 2018, at 1:39 am, Lukas Graf notifications@github.com wrote:

FYI, I've written a view that does exactly that (monkey patch Connection.register() to track changes) a while back in our own application. (Accompanying blog post here).

And it still can be very difficult to track down the culprit if you have multiple writes to multiple objects in the same transaction: Even if you were to track all the call stacks that cause an object to be registered, you still can't be sure which one contains the offending write. As a human. Let alone as a piece of code that's supposed to present to the human the exact traceback for the offending write.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.