Closed (fixed)
Project:
Field Empty Text
Version:
7.x-1.0-alpha1
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
22 Jul 2012 at 02:15 UTC
Updated:
22 Jul 2012 at 15:14 UTC
This is an admin only issue, so these are allowed to go through the public queues.
$empty_text = t($instance['field_empty_text']);
// Add a render array to output for the field formatter to display.
$output[$field_id] = array(
'#weight' => $instance_display['weight'],
'#label_display' => $instance_display['label'],
'#title' => $instance['label'],
'#bundle' => $bundle,
'#entity_type' => $entity_type,
'#field_name' => $field_id,
'#field_type' => 'text',
'#items' => array(),
'#formatter' => 'text_default',
'#theme' => 'field',
'#items' => array(
0 => array(
'value' => $empty_text,
),
),
0 => array('#markup' => $empty_text),
);
Two issues here:
$empty_text = t($instance['field_empty_text']);
This is wrong as far as the i18n guys are concerned, you should never run user text through t().
The security concern, which is only exposed if the user can configure fields. (thus the issue rather than kicking this off the main security channels)
0 => array('#markup' => $empty_text),
There is no checks on this text. I use the most permissive function filter_xss_admin(), although maybe fields should have the slightly more protective callback field_filter_xss() that is applied to field labels.
Comments
Comment #1
rypit commentedThanks for the feedback. I agree with you that we should be running filter_xss_admin at minimum on this. While I'm also inclined to agree about the use of the t() function -- (user text shouldn't be run through it), I would argue that for a multilingual site, it would be useful to have the empty text translatable.
Comment #2
alan d. commentedAny security related issue is critical even if it doesn't trigger emails to 100,000 users!
Personally, I never do i18n stuff so I don't worry about the details of t() and it's use, but both webflo and Gábor Hojtsy would strongly argue against this.
Comment #3
rypit commentedFair enough -- security patch being applied now. Also, in regards to t() -- field labels are run through it by default. The nature of field_empty_text is so similar to field labels that I feel like in this case the use of t is acceptable, and the benefits gained from it make the module far more useful for people with multilingual sites.
Comment #4
rypit commentedThanks for the report, opted to go with field_filter_xss as your recommended.
Comment #5
alan d. commentedNeither going to say ya or nay. Just being the messenger :)
Related: http://hojtsy.hu/blog/2011-may-19/drupals-multilingual-problem-why-t-wro...
But I'm not sure what part of the field module you are referring to, this is how I track it.
Maybe you are thinking pre-Drupal 7.2?
#1157512: Labels are not translated with i18n_field for Drupal core.
#1169798: Field labels are not translated anymore after upgrading to D7.2
Comment #6
rypit commentedThe main issue for this thread is the admin security issue which has been addressed (thanks again for pointing that out).
Common sense dictates that we should be able to translate the empty text. Please feel free to participate in the linked i18n threads to help them come to a conclusion regarding t() in field labels.
Comment #7
alan d. commentedThey have, to use I18n and to spend hours banging your head against a brick wall trying to figure it out...
Well actually, i18n_strings is now ported, and this is way easier than trying to implement some of the other methods.
I'm not doing it at all and wouldn't implement this unless there was a high demand or someone paid me too. :)