This is a follow up on #605572: %server variable no more accessible by anonymous users

Is it possible to have a value field that can handle ALL tokens? Maybe calling it something like "value". This would bypass any of the security issues associated with showing the super globals to users and allow people to record these without having to write any PHP


Members fund testing for the Drupal project. Drupal Association Learn more


Pixelstyle’s picture

I'm not able to contribute to the solution, but I will say that this would be greatly appreciated by many users. It will ensure a versatile webform module. %server[] in 2.7 could do some pretty neat things without any programming knowledge required.

quicksketch’s picture

Version: 6.x-2.x-dev » 6.x-3.x-dev

Moving to 3.x. I'm not sure about adding such a component.

jcarnett’s picture

Status: Active » Needs review
5.2 KB

Here's my 5-minute stab at it. Copied the hidden component, updated it to use a value form element, and changed the call to _webform_filter_values() to allow anonymous tokens. It works for me in my few quick tests.

Due to the way value elements work, it's unlikely this will do the trick for people looking to capture the referrer (that's gone by the time you get to the form submission), but other server variables, cookies, etc should work fine.

Patch is against 6.x-3.2, but I bet it'll apply against -dev as well.

Aside: Why not prevent page caching on pages where a webform uses "unsafe" variables so those forms at least work consistently?

legolas’s picture

Excuse me, how do i install this patch? I know patch
but i dont have a file called
Thank you

jcarnett’s picture

The patch adds To apply it, put the patch in the webform module directory and run:

patch -p0 < webform.value_component.patch
Danny Englander’s picture

subscribe, I am interested in this.

jcarnett’s picture

An updated patch is attached that adds input format support to the value component (i.e. to use PHP code).

Applies cleanly to 6.x-3.6, but should apply against -dev as well.

gorsti’s picture

Hi @jcarnett, I am looking to make the following work for anonymous users..


I am currently using 3.6 of Webform, so can apply the patch, however I am concerned as to my upgradability of the site, when the time comes to "drush up" everything....

I have built the site with nearly all released version code, 1 module I had to move to DEV to get launched , so my main concern with going with a patch for a core piece of functionality for the site would be - what happens next come time to upgrade modules - I note that you created the initial patch on Oct 15th, 2010, and there have been a few releases since then.....

Thanks for the patch, but would appreciate some guidance on what to do in terms of code managability - this is a new area for me, and a live site to consider.

Thanks /G

shrimphead’s picture


stevetweeddale’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
5.61 KB
5.62 KB

I made a new patch to implement a 'value' component in Drupal's pretty much a direct copy of the hidden component, just with the form api type changed. It doesn't do any of the PHP stuff that the previous D6 patches do, but it's a functional start.

I've included a patch made à la patch contributor guide, plus one with the --no-prefix option passed to format patch, so that it will play nice with drush make.

quicksketch’s picture

it's pretty much a direct copy of the hidden component, just with the form api type changed.

This thought has crossed my mind from time to time, what if we just made all hidden fields actually "value" by default? Most users aren't going to understand what a "value" field is, but we could just make the hidden component have an option like this:

[x] Make hidden field accessible through JavaScript (less secure)

If checked, we'll use a type="hidden" like we are currently. If left unchecked (the default), we use a #type = 'value'. What do you think?

stevetweeddale’s picture

Yeah, that sounds like a good idea to me - I might have a look at implementing that if I get the time. I reckon it probably makes more sense for end users to use the value type by default, and without having the overhead of a whole extra component type.

quicksketch’s picture

Status: Needs review » Needs work

I'm much more interested in the approach described in #11 than adding another (almost identical) component.

quicksketch’s picture

Status: Needs work » Needs review
2.28 KB

I looked into this today finally after marking a similar issue at #1232276: Options to make hidden fields value form elements, used to prevent email harvesting duplicate.

This patch adds a new "hidden type" display option that will allow the user to choose between the existing hidden field or using a "Secure value" field, which internally uses #type = 'value'. Because the likelihood of using the new hidden type is much more likely (and convenient, since it can handle all tokens without the troubles of the anonymous page cache causing stale values), I've made it the default. Further, because the default is applied to all existing installations, all hidden fields on existing sites will start using this approach rather than the old one.

This will cause breakage for a small number of sites that may be using JavaScript to manipulate the value of these fields, but I think that percentage must be very small compared to the number of users who would benefit from greatly increased security of a truly "hidden" field that can't be scraped for e-mail addresses or other supposedly "hidden" data.

quicksketch’s picture

Title: A value field for handling unsafe tokens » Allow hidden fields to handle unsafe tokens by making the "value" type fields
Status: Needs review » Fixed

Patch applied and works for Drupal 6 too, Committed to both branches.

danmed’s picture

certainly a good move for the reasons mentionned, but one should also be carefull to review PHP code if one implemented hook_form_alter to retrieve and act upon hidden field values.
In such cases, one must modify the code there and replace

this is what I am currently doing throughout my code...

Status: Fixed » Closed (fixed)

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

pianomansam’s picture

@quicksketch Could you consider not making the default hidden field be the new secure type, for backward compatibility? Or at least warn the site administrator when they upgrade to 3.16+ so they aren't caught off guard? I was caught off guard pretty well because of my use of JavaScript to change a hidden value. Seeing that this is only an incremental upgrade, but this is a huge change in behavior, an additional warning would be beneficial.

quicksketch’s picture

Could you consider not making the default hidden field be the new secure type, for backward compatibility?

I think the move was justified as I described in #14, but you're right that more warning should have been in place for users upgrading from versions before 3.15. At this point, I'm not sure what mechanism we can use to warn administrators. Most users don't read the release notes for new versions, and almost no one reads CHANGELOG.txt (I personally don't either, which is why it's out of date and really should probably be removed). With tools like Drush out there, more experienced users don't visit when doing module updates. I suppose we could make an empty update hook that does nothing but provide a warning?

pianomansam’s picture

I suppose we could make an empty update hook that does nothing but provide a warning?

That seems to be a reasonable approach.

druderman’s picture

Version: 7.x-3.x-dev » 6.x-3.17

FYI, adding the secure option and changing the default actually broke all the webforms on my site, because we relied on allowing JS to write to the fields. After some investigation, I guessed that an update like this was recently applied. ...Just saying. Meanwhile, thank all otherwise for the good work on a good module.

gregoryshearer’s picture

I just discovered this issue and I am glad I did because this upgrade will break dozens of forms across dozens of sites for us if it is applied. Literally all of our webforms rely on javascript now since the Additional Validation/Processing fields were removed along with the session and server variable tokens.

I am looking at the webform_component table and it looks like the only thing that changes when you change a hidden field from "Secure value" to a hidden element is in the "extra" field where the string s:5:"value"; gets changed to s:6:"hidden";

Can anyone confirm that this is the only change this setting makes in the database and would it be safe to update this value across all forms in a database via a SQL replace function?

I also politely disagree with Quicksketch that #14 justifies setting this as a default setting. This is new functionality (albeit GREAT new functionality) that breaks existing behavior when implemented. While it may be true that fairly few sites actually rewrite hidden fields with javascript, I'd counter that those who do this would tend to be like us and do it on a LOT of forms. I know we are in the minority though and I am hoping this can be fixed progammatically in the database directly.

Alan D.’s picture

On existing forms, what did the update do, did it default to 'value' rather than maintaining the existing behaviour, i.e. 'hidden'?

From D7, very likely to be in D6 too:

drupal_alter('webform_component_info', $components);

This can allow you to programmatically change the default value set here:

function _webform_defaults_hidden() {
  return array(
    'name' => '',
    'form_key' => NULL,
    'pid' => 0,
    'weight' => 0,
    'value' => '',
    'extra' => array(
      'private' => FALSE,
      'hidden_type' => 'value', # this bit to alter. Set to hidden instead

This should work if the component has not be edited yet as I can not see a physical upgrade script that does it in my current version of webform (7.x-3.17).

[edit] i.e. the component key doesn't exist, so when the component is loaded, this value would be defaulted to the defined component default.

acbramley’s picture

I've upgraded to Webform 7.x-3.18 to get this hidden component type, I've used the Secure value hidden type and using the default value of %server[HTTP_REFERER]

I'm using this for a feedback form but the hidden field isn't getting populated with the correct referer url, rather it is being populated with the url of the webform (e.g When I use this token in a textfield and submit as the admin user I'm getting the correct referer url in the results. What's causing the incorrect url in the hidden field? It seems like this was the exact use case this patch was made for but it isn't working for me.


acbramley’s picture

Status: Closed (fixed) » Needs work

Forgive me if I'm wrong in doing this, but I'm reopening this in regard to my previous comment as it seems like the functionality is not working properly

acbramley’s picture

Would appreciate some feedback on #24 as I really need to get this working!

quicksketch’s picture

Status: Needs work » Closed (fixed)

Let's reconvene in this bug report: #1580700: Hidden "secure value" component losing its token (%get, %post) value on webform submission. As a feature, this issue is complete (though apparently not working correctly currently).

jonlibrary’s picture

I couldn't get this to work in D6; I ended up using hook_form_alter in a custom module on a textfield:

function your_module_name_form_alter(&$form, $form_state, $form_id) {
  if ($form_id == 'webform_client_form_id') {
    $url = referer_uri();
    $form['submitted']['your_field']['#default_value'] = "$url";

I also use the CacheExclude module to keep the form from being cached.

I don't know how any of this differs in D7. See and #1298220: hook_form_alter fails to prepopulate the default value for a webform component before rendering the client_form.

Would filter_xss need to be added? // This question added 9/25/12