Pull Request for Issue https://github.com/joomla/joomla-cms/pull/32207#issuecomment-770230746 .

Summary of Changes

Let the input filter also clean objects.

Due to the recursion, the clean function will also work for nested objects.

Testing Instructions

Test https://github.com/joomla/joomla-cms/pull/32207 and see that it fails.

Then still on the same testing environment, apply the same change as made in this PR here for the 1.x version of the input filter to the local 2.0.0-beta4 version of the input filter, and then test again, and check that it works now and that changed filters are properly saved in database.

Documentation Changes Required

None.

• Adds basic first level processing of array's of numbers
  • Fixes Array to String conversion notices in clean() for number cases
• Replaces decode() with html_entity_decode()
• Updates pcre patterns for numbers
  • Fixes floats case to properly handle exponent type floats rather than just decimal floats
• Adds new general cases to test and verify the array of numbers functionality
• Code style: fixes missing comma at end of array lists.

Steps to reproduce the issue

It seems that beginning with version 2.0.0-beta3, the filter package breaks saving Global Configuration in the 4.0-dev branch of the CMS, see https://github.com/joomla/joomla-cms/pull/32207#issuecomment-770240778 .

I.e. update the filter package on J4 to version 2.0.0-beta3 or 2.0.0-beta4. Then go to Global Configuration and try to save.

Expected result

Works.

Actual result

PHP Recoverable fatal error:  Object of class stdClass could not be converted to string
in /home/richard/lamp/public_html/joomla-cms-4.0-dev/libraries/vendor/joomla/filter/src/InputFilter.php on line 239,
referer: https://www.joomla-40-dev.vmkubu02.vmnet2.local/administrator/index.php?option=com_config

System information (as much as possible)

Additional comments

Pull Request for Issue #

Summary of Changes

Fix the regex for Windows so it can handle partly normalized paths like e.g. C:\\xampp\\htdocs\\joomla-cms/tmp, which is the $tmp_path in configuration.php after a new installation of a current staging branch of the CMS on an XAMPP on Windows.

Partly normalized paths like e.g. C:\\xampp\\htdocs\\joomla-cms/tmp are absolutely ok in environments like PHP or like I have it in my job with Java, where paths on any OS are later normalized using "/" as separator (what out Path::clean does).

So we have to stick here to the rules of PHP how it handles Windows paths, and not to the rules of Windows, where a slash in a file or folder name is not allowed.

@zero-24 @nibra If having partly normalized paths like described above is not desired, we can replace the slashes / by backslashes \ at the end of the routine here https://github.com/joomla-framework/filter/blob/872338c69e1539959d05059d533a483edcc76978/src/InputFilter.php#L1018 by changing it to return preg_replace('~(\\\\|/)+~', '\\', $source); Then we would not have 'C:\Documents\Newsletters/tmp' or 'C:\Documents/Newsletters/tmp' but 'C:\Documents\Newsletters\tmp' as result of the 2 new unit tests.

I think we don't need that, i.e. the PR is good as it is, because when appending the update package's file name to the path, the Joomla Update component will anyway use a slash /.

What do you think?

Testing Instructions

Test https://github.com/joomla/joomla-cms/pull/32076 with XAMPP on Windows.

Documentation Changes Required

None.

Pull Request for Issue #

Summary of Changes

This PR fixes the issue on Joomla CMS PR https://github.com/joomla/joomla-cms/pull/32207. Basically, we should only call the type specific filter method if $type is actually passed (not an empty string).

I don't know what is testing instructions. Maybe code review should be enough?

Pull Request for Issue Port CMS fix 15966

Summary of Changes

Port CMS fix 15966 - Fixing InputFilter adding byte offsets to character offset

Testing Instructions

Should pass filtering this included content content.txt

unit tests based on this and other content provided by Joomla users and tests created by @PhilETaylor are included

Documentation Changes Required

none

Pull Request for Issue #N/A

Summary of Changes

Currently, joomla/filter cannot be installed on PHP 8.0 due to the following error:

Problem 2
    - joomla/filter is locked to version 1.3.5 and an update of this package was not requested.
    - joomla/filter 1.3.5 requires php ^5.3.10|~7.0 -> your php version (8.0.3) does not satisfy that requirement.

However, your automated test suite already seems to be testing it against PHP 8.0 and it works just fine! This PR explicitly describes support for PHP 8.0.

Testing Instructions

N/A

Documentation Changes Required

Pull Request for Issue #

Summary of Changes

Fix the new test for object.

The same test for non-objects uses the unknown filter type ''.

It should be the same when testing the object.

Testing Instructions

CI tests pass.

Documentation Changes Required

None.

Pull Request for Issue https://github.com/joomla/joomla-cms/pull/32076 cc @richard67 @nibra

Summary of Changes

Add an windows test with slash

Todo

• [ ] extende the regex to allow the slash at the right place or
• [ ] require the path to be passed via path::clean

Testing Instructions

Try to test the PR #32076 the test fails as there is a slash in the regex

Documentation Changes Required

none.

Steps to reproduce the issue

var_dump((new Joomla\Filter\InputFilter)->clean(1, 'raw'));

Expected result

int 1

Actual result

string '1'

System information (as much as possible)

Additional comments

Since https://github.com/joomla-framework/filter/commit/e4d3d158eabae41edfdbfea482a2b5feae71a187.

Back port unit tests from joomla-cms https://github.com/joomla/joomla-cms/commit/61b9fcc4702467fdb0500057c49577037561fcc1

@mbabker https://github.com/joomla/joomla-cms/issues/16088#issuecomment-302196249

Steps to reproduce the issue

This is an issue that was found out in https://github.com/joomla/joomla-cms/pull/38993 and is still valid in the current codebase of the filter package. In https://github.com/joomla-framework/filter/commit/0556634b23b8f3041576301c5aefb60baff40e93 the language class from the CMS is used in the OutputFilter class and besides that, the use-statement is wrong. So right now this stringUrlSafe() does not work.

( ! ) Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in \libraries\vendor\joomla\filter\src\OutputFilter.php on line 157

Pull Request for Issue #

Summary of Changes

Testing Instructions

Documentation Changes Required

Steps to reproduce the issue

1. Apply the path filter to the path

/var/www/vhosts/website-net/subdomain-website-net/._hiddenTemp

2. Apply the path filter to the path

/var/www/vhosts/website.net/subdomain.website.net/._hiddenTemp

Expected result

1. Should return the cleaned path

/var/www/vhosts/website-net/subdomain-website-net/._hiddenTemp

2. Should return the cleaned path

/var/www/vhosts/website.net/subdomain.website.net/._hiddenTemp

Actual result

1. Returns the path

/var/www/vhosts/website-net/subdomain-website-net/._hiddenTemp

2. Returns an empty path

``

Additional comments

Plesk servers use the domain/subdomain pattern 2 so this is a live issue.

Additionally the use of hidden files/folders is a valid and security enhancing use case - setting the Joomla tmp or log directory to a hidden *nix folder is a good thing. Also can be used to install a hidden Joomla installation in an obscure and hidden sub-folder of a live site.

…ibute values

I had a closer look to the problem with the "infinite loop" (which means that at the end you are running into the maximum execution time error) mentioned in joomla/joomla-cms#34967.

The problem is, that escapeAttributeValues() does not handle multibyte characters correctly. It makes wrong replacements in the tag attribute values which leads to the "infinite loop" in the further processing after the function has been applied.

One can reproduce the wrong replacement by doing the following changes to a fresch installation of Joomla 4.0.0

1. Change the access of the function protected function escapeAttributeValues($source) in /libraries/vendor/joomla/filter/src/InputFilter.php from protected to public.
2. Add the following code to line 179 of administrator/components/com_cpanel/src/View/Cpanel/HtmlView.php

		$inputFilter = \Joomla\CMS\Filter\InputFilter::getInstance(array(), array(), 1, 1);
		$testhtml = '<input alt="PayPal – The safer, easier way to pay online!" name="submit" src="https://www.paypalobjects.com/de_DE/CH/i/btn/btn_donateCC_LG.gif" type="image" />';

		echo "<p>Before applying escapeAttributeValues():<br/>";
		echo(htmlentities($testhtml));
		echo "</p>";
		echo "<p>After applying escapeAttributeValues():<br/>";
		echo(htmlentities($inputFilter->escapeAttributeValues($testhtml)));
		echo "</p>";

3. Open the Joomla 4 dashboard in the backend. Notice the hyphen in the "alt" attribute of the input tag, which is a multibyte character (3 bytes). See the wrong replacements ... online!" "ame=.

The problem is, that $matches[0][1] counts in bytes and $attributeValue = StringHelper::substr($remainder, $nextBefore, $nextAfter - $nextBefore); counts in multibyte characters.

After applying the patch there is no wrong replacement any more.

Paths with dots at the beginning of folder or file name doesn't pass current path filter regular expressions. For example /var/www/.secret doesn't pass, even it is valid path. This influence Joomla CMS update system, when used such path for global temp dir.

Steps to reproduce the issue

Set in Joomla global configuration Temp path with hidden folder (starting with dot), for example /var/www/.tmp. Go to Joomla update component and try to download and install update.

Expected result

No error, update is installed.

Actual result

Error is displayed, update is not installed.

System information (as much as possible)

Joomla CMS with Joomla Filter 1.4.3

Additional comments

This is B/C break in Joomla CMS, as it influence Joomla update system. Path doesn't pass filter, so returns empty string, which causes updater to fail download update file, with incorrect error message.

Tried to solve it in https://github.com/joomla/joomla-cms/pull/33151, which was incorrect, as I was noticed of double dots folders (and also PR to wrong project :))

So if you run a string containing a symbol < through the filter class then you find that it gets stripped.

It's something inside the tag cleaning - but obviously we don't want all < tags to be stripped