Especially for the entity types now contained in some labels (#2470958: Fields UI shows @label ID instead of the proper text) we should check whether adding something like & to a field and/or entity type name results in correctly escaped output on the Fields page. (I don't think it's currently anywhere else?)

Remaining work

  1. Fix ::checkFieldLabels
  2. Add a test-case that changes the indexname and servername

Estimated Value and Story Points

This issue was identified as a Beta Blocker for Drupal 8. We sat down and figured out the value proposition and amount of work (story points) for this issue.

Value and Story points are in the scale of fibonacci. Our minimum is 1, our maximum is 21. The higher, the more value or work a certain issue has.

Value : 8
Story Points: 3

Comments

Nick_vh’s picture

Issue summary: View changes
Issue tags: +beta blocker
borisson_’s picture

Status: Active » Needs review
FileSize
2.06 KB

Locally this doesn't work, but it should. Let's see what the bot thinks.

Status: Needs review » Needs work

The last submitted patch, 2: verify_field_labels_are-2473267-2.patch, failed testing.

drunken monkey’s picture

+++ b/src/Tests/IntegrationTest.php
@@ -88,6 +93,39 @@ class IntegrationTest extends WebTestBase {
+    $field_name = '^6%{[*>.<"field';
…
+    $this->assertRaw($field_name);

Doesn't this test exactly the opposite of what it should – i.e., that the field name occurs in the raw HTML as-is instead of escaped?
I think assertText($field_name) or assertRaw(Html::escape($field_name)) would be correct instead.

borisson_’s picture

Status: Needs work » Needs review
FileSize
835 bytes
2.29 KB

Thanks for the suggestion in #4. Test should pass now.

drunken monkey’s picture

Status: Needs review » Needs work

Looks better, thanks.
However, would it be possible to instead integrate it into the existing test*() method, so it won't run separately (and require its own site install). I know it's rather bad practice, but I can't really see it does much harm, and it certainly keeps the test run time down.

Also, it would be nice to also go to the "Processors" tab and verify that neither content type (for the "Rendered item" processor) nor field name appear unescaped there. (We should add that for the existing tests, too – it should appear escaped, and should not appear unescaped. Otherwise, it might just be escaped in one place, but unescaped in another. And we might even want to check it doesn't appear double-escaped. Maybe use a helper method for that.)

Third item: We should also change the index and server name to something with & in it and check whether this is always escaped properly. This is something we actually had problems with, having the index name unescaped inside the <title> tag, I think.

Finally, also verifying everything is properly escaped in Views would be ideal – but probably a bit too much. Even if we'd add it to the Views test, where Views is already enabled anyways, we'd still need to enable Views UI. We might want to at least add a separate issue for that, though.

Do you want to make those changes yourself or should I?

borisson_’s picture

Issue summary: View changes
FileSize
3.57 KB
3.5 KB

Some work done, needs more work. I'll look into that tomorrow.

borisson_’s picture

Status: Needs work » Needs review
FileSize
6.14 KB
8.99 KB

I haven't added any test cases for the views related stuff yet and I think we should add that in a seperate issue anyway. I found one issue; so that's great!

drunken monkey’s picture

Status: Needs review » Needs work

Great job, thanks!
And even better if this actually found something!

I also agree with you, the view stuff can and should follow in a separate issue.

Regarding the fix for the problem, though:

+++ b/src/Item/FieldTrait.php
@@ -317,7 +318,7 @@ trait FieldTrait {
         try {
-          $this->labelPrefix = $this->getDatasource()->label();
+          $this->labelPrefix = Html::escape($this->getDatasource()->label());
         }
         catch (SearchApiException $e) {
           watchdog_exception('search_api', $e);
@@ -325,7 +326,7 @@ trait FieldTrait {

@@ -325,7 +326,7 @@ trait FieldTrait {
         $this->labelPrefix .= ' » ';
       }
     }
-    return $this->labelPrefix . $this->getLabel();
+    return $this->labelPrefix . Html::escape($this->getLabel());

I don't think that's the proper place to fix that, it's not the job of the field object to return sanitized labels (especially if it's not documented that way).
Where is that actually used and displayed unsanitized? The escaping should be done there – and, optimally, in a way that avoids double-escaping. I think Html::escape() should usually not be used, since this doesn't mark the string as "sanitized", leading to potential double-escaping.

+++ b/src/Tests/IntegrationTest.php
@@ -640,4 +726,16 @@ class IntegrationTest extends WebTestBase {
+   * Test for how well a string is escaped.

The first line of a function/method doc block (same for classes/interfaces/traits) should start with a verb in third person. I'd rename that method to assertHtmlEscaped(), though, and document it with something like "Ensures that all occurrences of the given raw string in the page are properly escaped."

borisson_’s picture

Status: Needs work » Needs review
FileSize
5.42 KB
9.04 KB

Fixes remarks made in #9.
Still using Html::escape, it was going wrong in the FieldsProcessorPluginBase::buildConfigurationForm

drunken monkey’s picture

Component: Framework » Tests
Status: Needs review » Fixed

Nice job, looks great. Thanks!
Committed.
(After re-arranging the test methods to be in the same order as called, and adding a single "s".)

Status: Fixed » Closed (fixed)

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