According to the code, and as it should be, the %post token is a safe token. However, the documentation (still) states

In addition to %get, the following super tokens may be used, though only with logged-in users: %server, %cookie, %request and %post. For example %server[HTTP_USER_AGENT] or %session[id].

Proposed documentation change:

      'description' => t('In addition to %get, the following super tokens may be used, though only with logged-in users: %server, %cookie, %request and %post. For example %server[HTTP_USER_AGENT] or %session[id].'),

to:

      'description' => t('In addition to %get, the following super tokens may be used: %post, %server, %cookie, and %request. However, except for %post, these may only be used with logged-in users. For example %server[HTTP_USER_AGENT] or %session[id].'),

But I'm not a native English speaker, so you might come up with a better formulation.

CommentFileSizeAuthor
#3 webform_post_safe-d6.patch1.13 KBquicksketch
#3 webform_post_safe-d7.patch1.12 KBquicksketch

Comments

quicksketch’s picture

quicksketch
he/him
commented

I'll need to double-check if POST is safe or not. If a user visits a page at http://example.com/node/10 while submitting a POST request, the HTML rendered to the page may contain a %post[value] token set by Webform. If this value were cached in the page cache, that could cause some serious issues with one user's POST information being displayed to another anonymous user when http://example.com/node/10 is viewed.

I'm not clear right now whether or not Drupal tries to cache a page that is submitted as a POST request. If it doesn't cache pages that have been POST requested, then you're right that the %post tokens can be included as "safe".

fietserwin’s picture

fietserwin
Location Le Mont-Dore
commented

Good thinking, though POST should never be cached, not in browsers, not in proxies, and not in servers, not even if you could make the content of the post body part of the cache key, because a POST is allowed (assumed) to have side effects.

Anyway, I have sought this out for you (best way of learning how Drupal works):

File: bootstrap.inc

function drupal_page_is_cacheable($allow_caching = NULL) {
  $allow_caching_static = &drupal_static(__FUNCTION__, TRUE);
  if (isset($allow_caching)) {
    $allow_caching_static = $allow_caching;
  }

  return $allow_caching_static && ($_SERVER['REQUEST_METHOD'] == 'GET' || $_SERVER['REQUEST_METHOD'] == 'HEAD')
    && !drupal_is_cli();
}

Oh: I just noticed that the documentation doesn't list %session as existing, it is only mentioned as an example. So that sentence need to be rephrased once more.

quicksketch’s picture

quicksketch
he/him
commented
Status: Active » Fixed
StatusFileSize
new webform_post_safe-d7.patch1.12 KB
new webform_post_safe-d6.patch1.13 KB

I've committed these patches which update the token descriptions to reflect %post as a safe token.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.