[FLOW3-general] RFC: Disable automatic persistence for GET requests

[Bastian Waidelich]

Hi all,

at the risk of being annoying... ;)

the subject says it: I'd like to suggest a kind of radical change, that 
disables persistAll() to be called automatically on GET requests.
I already started this discussion in the chat today and I know, that 
it's a bad time to ask for yet another breaking change. But IMO we 
should at least spend some thoughts about this before the release in 
order to have a common strategy.

I collected some pros and cons, please comment:


CON:
- people will expect changes to be persisted automatically

True, but I think we have the chance to make that a core concept of 
FLOW3 and everyone that read the "getting started" tutorial will know 
about this - just like every developer has to learn, that you have to 
add certain annotations here and there.

- people will call persistAll() themselves

The risk is there, but the convention would be to use a different 
request method (like POST).
In order to avoid persistAll() from being called multiple times, we 
could add a convenience method to the Web\Request that manually 
re-enables the automatic persistence for GET requests.

- it's not as convenient to create delete links

Right now, creating a link that deletes/modifies entities is really easy 
and we even use this in the Conference package (shame on me):

<f:link.action action="delete" arguments="{foo: foo}">delete</f:link.action>

But actually this is really bad practice, as search engines or other 
automated agents will follow those links (usually these are protected by 
a login, but imagine a custom crawler or an intermediate state with 
missing policies).
GET is considered a safe method. This is not some REST stuff, this is 
defined in the HTTP standard [1].

One alternative would be to create a form for every delete link. With 
Fluid that is actually pretty easy too:

<f:form action="delete" arguments="{foo: foo}"><f:form.submit 
value="delete" /></f:form>

An argument came up, that this would be the first time that we enforce 
special markup, but that's not really true because a) we already create 
some custom markup if you use the default view helpers and b) this 
should be a *convention* that could be circumvented if someone insists 
(see above).

Another alternative would be to use AJAX POST/PUT/DELETE requests 
(That's btw also a nice way to add logging or counters without a 
performance hit).


That were the major drawbacks I could come up with. Can you think of more?


PROS:
+ performance

Usually more than 90% of the requests are readonly. It would probably be 
a huge speedup to avoid all the dirty checks for those.

+ caching

Caching would be more efficient if we could assume that GET requests are 
stateless. Also it would probably make it much easier to integrate 3rd 
party proxies like varnish.

+ nicer URLs

Currently all links that point to a protected action will - by default - 
have a CSRF token appended, that looks like 
"?__csrfToken=3cb0adda641c1eac31b099cecd7055bd". The main reason why we 
need this is because a GET request could be dangerous.

+ HMAC

IMO the HMAC is a really convenient way to add touchless security on a 
granular level. Imagine you can install a user registration package and 
define what fields can be modified only by editing the Fluid template..
One of the problems of our previous implementation was, that it was 
difficult to tell when an HMAC was required. With this change we could - 
by default - require it for all POST/PUT/DELETE requests.


What do you think?




[1] http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods