-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improper and useless error reporting #71
Comments
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. |
FYI, I've written a view that does exactly that (monkey patch And it still can be very difficult to track down the culprit if you have multiple writes to multiple objects in the same transaction: |
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 ***@***.***> 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.
|
This is a followup of
plone/Products.CMFPlone#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.
The text was updated successfully, but these errors were encountered: