OWASP recommends escaping the forward slash character in addition to the other characters normally escaped with PHP's htmlspecialchars() method. Any thought to adding that to the escapeHTML() method?

• I was not able to find an open or closed issue matching what I'm seeing.
• This is not a question. (Questions should be asked on chat (Signup here) or our forums.)

The example used on https://docs.zendframework.com/zend-escaper/escaping-url/ is not only building a URL. It is also outputting this URL in an HTML context. So this is a case of nested contexts:

• the name must be escaped as URL component (good)
• the whole URL must be escaped as HTML attribute value (not good currently)

This is kind of unfortunate to show this as a good usage of escaping when a previous chapter was precisely warning about nested contexts.

The example should either be improved to apply the necessary HTML escaping, or be replaced by another example using the URL in a non-HTML context.

Check docs for other problems

TLDR; Cast your eye over the documetation for any problems not covered in the other issues

Things slip through the net, so check the documentation for other problems that have been missed. Common other problems include

• Bullet lists (should be single * then space at the start of line)
• Inline code - should be marked by three backticks at start and finish
• bookdown.json file is correctly formated and has the right escaping
• Links between documentation using RST have been stripped
• Any other RST has been removed correctly
• Anything and everything not covered

If you end up fixing the same problem over and over, please ping Gary Hockin - we may be able to add bespoke issue for that problem, or fix in automated capacity

Check the tables in a document

TLDR; All tables should be in the format of GHFM using | and - as horizontal and vertical separators respectively

Check all tables are in the correct format. Please don't use leading and trailing | - more information on github flavoured markdown tables can be found here.

Check the document for bad blockquoutes

TLDR; Check blockquotes are formatted correctly using > and check headings in blockquotes are using ###

Blockquotes are donated by a single greater than character and then a space. Make sure all the blockquotes in every doc file are correctly formatted. Headings in blockquotes should use ### and not bold.

Any paragraph spacing in blockquotes should be marked using a single greater than, then a space.

Afaik ZF2 doesn’t ship a default View Helper to escape strings within view scripts. The docs say you need to instantiate a custom escaper in the view script.

This seems clunky to me. Is there any reason, zend-escaper doesn’t provide a View Helper?

Which requires escaping a large number of characters in attributes? [^a-z0-9,\.\-_]
URL's in html looks ugly and are larger than possible

<a href="https&#x3A;&#x2F;&#x2F;www.example.com&#x2F;">
<a href="https://www.example.com/">

• Update Travis configuration
• Check Travis results

Related to #26

Check code blocks are correct

TLDR; Check in all files that codeblocks are correct, in PSR-2 format and have PHP syntax highlighting applied.

Code blocks should be in the following format...

```php
 'ZEND-FRAMEWORK');

// No required options
$rendererOptions = array();
$renderer = Barcode::factory(
    'code39', 'image', $barcodeOptions, $rendererOptions
);

```

Note the three backticks then php in the opening fence, and the closing fence is just three backticks. It's common for the opening backticks to have no code type, or something like source.

Code should also have been automatically formatted into PSR-2 format, but sometimes these slip through the net.

Check headers are correct

TLDR; Headers should use the #, ## etc to format different levels of headers, and not be underlines using ===== or ``-----`, or be psuedo header using bold

Check all headers on the documentation - headers should use the hash style of declaration rather then be underlined with equals or dashes. The more hashes, the more of a subheading. Eg:

• # is equal to <h1>
• ## is equal to <h2>
• ### is equal to <h3>
• #### is equal to <h4>
• ##### is equal to <h5>

Headings should be appropriate for their level in the documentation.

Psuedo headers using bold tags ** should be replaced with appropriate level of heading tag.

For an example, take the character "🍥" (FISH CAKE WITH SWIRL DESIGN, U+1F365)

escapeHtml, since it uses htmlspecialchars, just passes this through unchanged.

On the other hand, escapeHtmlAttr internally tries to convert it to UTF-16 big-endian, resulting in the sequence D83CDF65 and a final output of �. That's not a valid HTML character reference for anything. The correct character reference in this case would be 🍥.

What it looks like is happening is that the escaper code always assumes that converting to UTF-16 will be always be sufficient to return a direct codepoint value as required for an HTML entity, but that's not correct. Characters from beyond the Basic Multilingual Plane will be encoded in UTF-16 as a surrogate pair. The incorrect attempt to print this result is how you get the crazy 8-hex-digit value instead of the appropriate 5 digits for the "fish cake" example.

It's possible to instead convert the input into UTF-32BE, which doesn't use surrogate pairs for any Unicode codepoint. The rest of the logic used by escapeHtmlAttr should then work fine.

This issue has been moved from the zendframework repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/7681
User: @mkEmperor
Created On: 2016-03-03T15:20:23Z
Updated At: 2016-03-07T02:09:36Z
Body
$this->add(array( 'name' => 'name', 'attributes' => array( 'type' => 'text', ), 'options' => array( 'label' => 'Имя', ), 'attributes' => array( 'required' => 'required', 'placeholder' => 'Имя' ), ));
$this->add(array( 'name' => 'submit', 'attributes' => array( 'type' => 'submit', 'value' =>'Зарегестрироваться' ) ));

in form
<input name="name" required="required" placeholder="&#xD098;&#xD0BC;&#xD18F;" type="text" value="">
<input name="submit" type="submit" value="&#xD097;&#xD0B0;&#xD180;&#xD0B5;&#xD0B3;&#xD0B5;&#xD181;&#xD182;&#xD180;&#xD0B8;&#xD180;&#xD0BE;&#xD0B2;&#xD0B0;&#xD182;&#xD18C;&#xD181;&#xD18F;">

Comment

User: @mkEmperor
Created On: 2016-03-03T15:22:46Z
Updated At: 2016-03-03T15:22:46Z
Body
Project and all files in utf-8

Comment

User: @mkEmperor
Created On: 2016-03-03T16:10:36Z
Updated At: 2016-03-03T16:11:01Z
Body
public function escapeHtmlAttr($string) { $string = $this->toUtf8($string); if ($string === '' || ctype_digit($string)) { return $string; } $result = preg_replace_callback('/[^a-z0-9,\.\-_]/iSu', $this->htmlAttrMatcher, $string); return $this->fromUtf8($result); }

correct '/[^a-zа-яА-я0-9,.-_]/iSu'

This issue has been moved from the zendframework repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/7550
User: @phpManiac77
Created On: 2015-05-25T13:32:36Z
Updated At: 2015-11-06T21:53:56Z
Body
Method Zend\Escaper\Escaper::escapeHtmlAttr() should use [:alnum:] in the regular expression. So it would also work with chinese characters correctly.

Comment

User: @Ocramius
Created On: 2015-05-25T13:41:43Z
Updated At: 2015-05-25T13:41:43Z
Body
Any non-ascii characters are supposed to be encoded anyway.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 25 May 2015 at 14:32, phpManiac77 [email protected] wrote:

Method Zend\Escaper\Escaper::escapeHtmlAttr() should use [:alnum:] in the
regular expression. So it would also work with chinese characters correctly

—
Reply to this email directly or view it on GitHub
zendframework/zendframework#7550.

This issue has been moved from the zendframework repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html

Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/7621
User: @esase
Created On: 2015-08-28T16:08:25Z
Updated At: 2015-11-06T22:20:41Z
Body
I didn't see this trouble before but when I updated my Zend with the latest 2.5.1 I see the very strange behaviour. All form elements show me Chines characters like this 킞톂킿톀킰킲킸톂톌 instead of Войти (Russian) e.g.

It happens only on windows platform, on Linux everything is ok.
My work environment is:
OS: Windows
PHP: 5.4.12
Site locale: ru_RU

I found this issue here - zend-escaper\src\Escaper.php in htmlAttrMatcher($matches) method

PS: For English everything is ok

Comment

User: @esase
Created On: 2015-08-31T06:37:51Z
Updated At: 2015-08-31T06:37:51Z
Body
Anyone?