When plone.protect 3.0.x is used in Plone 4.3.x, object (tab) actions on content in my site have _authenticator values/params appended to the querystring of the URL. Is there a way to avoid this specific behavior?
This URL appending has subtle but frustrating side-effects (e.g. my use of plone.schemaeditor was broken by it, which forced me to fork plone.schemaeditor for my purposes).
Sean
Yes. Use POST requests with the _authenticator param, use the header approach or don't write on read.
I share your frustration and had similar issues. I ended up to disable the CSRF protection using
alsoProvides(self.request, IDisableCSRFProtection).
It is not in the scope of Plone to requires not to write to the database as part of a GET operation.
GET only defines a contract between browser and backend. It does not tell me what to do internally.
So this whole assumption that writes should only happen upon POST and PUT is wrong and broken.
-aj
The changes introduced in plone.protect to Plone 4 via a security hotfix weren't meant to force the REST ideology upon us.
It is meant for preventing potential security issues.
I should clarify, I just want to avoid ugly URLs in object tab actions. Surely there must be a way to avoid having the parameter in each rendered href?
Sean
+1
as with various other design decisions lately: this is a shortsighted and unmindful change; a behavioral change breaking compatibility of various code.
-aj
They can be removed if we stop doing write on read.
Unfortunately, the code base was too complicated to fix every instance programmers were lazy over the years with write on read, not to mention all the add-ons that do it.
The problem was especially bad in Zope2 where there were countless places there is write on read and countless places with no CSRF protection.
It was a compromise to do it this way. Do we like the URLs? Of course not. But it's a solution that solves a serious problem.
We knew it was a tough hotfix and there would be problems--we are just trying to do the best compromise and be responsible.
@zopyx Do you have a better solution to the problem than our shortsighted and unmindful change? Re-write Zope2 in a hotfix?
Consider white-listing portions of the UI in the transform, such that href in child elements of those areas are not touched by this? I would think there are some safe places, esp. if our primary and inextinguishable hornet's nest is the ZMI?
We considered it. What add-ons do it unpredictable even for just "View" when logged in though.
What we can do as an alternative is start checking the referrer/origin instead of strict auth token checking. However, that would probably need a whitelisting as well because checking referrer/origin doesn't protect against attacks originating from your own server(say in comments on a blog post).
If had be me to write these words I bet my post will be erased, like two of my posts someone censored and deleted here in this "community" forum days ago. Nice!
(and my words were no more harsh than Andreas words here...)
(and I will emphazise shortsighted and unmindful...)
About plone.protect, yes, it is a nuisance, but the benefits surpass the problems, I think better docs and code examples will help a lot to deal with it.
perhaps his post was not flagged/deleted because he is not just simply insulting someone but expressing his point of view.
besides that, everybody knows who Andreas is, how he interacts and, more important, what he has done for Zope/Plone over many years.
he is not hiding himself, trying to influence the community (without quotes) behind a green avatar like others do.