How unsafe is %post in token replacement?
helmo - November 5, 2009 - 15:08
| Project: | Webform |
| Version: | 6.x-2.8 |
| Component: | User interface |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
For token replacement in the _webform_filter_values function only %get is put in the 'safe' state by default. Making me wonder why %post is not.
From the comments and CVS commit message I understand that this was done to prevent the caching of posted userdata.
I would however not expect a page requested via POST to be cached.
For a site I'm working on I would like to prefill a textarea with a dozen lines of plain text from a POST value.
For logged-in users this works fine, however not for anonymous visitors.
Placing %post in the 'safe' part of $special_tokens makes this possible also for anonymous visitors.
Is there however a clean/safe way to accomplish this?
Or would you suggest using a different approach to this?
#1
subscribing
#2
%get is safe because $_GET values are pulled from the URL, such as http://example.com/form?value=something. Since every change to the $_GET string will create a different URL, every one of these pages will be cached separately. So it's impossible to "accidentally" expose another user's information at the same URL. Using %post, a visit to http://example.com/form could be populate with the previous user's information, since it's at the exact same URL, which would be stored in the cache.
#3
I've been digging around a bit more on POST and caching...
RFC 2616(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html) states in section 9.5 "Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. "
And also Drupal's page_set_cache() does a very explicit if on "$_SERVER['REQUEST_METHOD'] == 'GET'"
This makes me believe that %post is just as safe as %get, as both could contain user data.