Article can't be saved/updated by the user after 3.7.0 updation #15673
Comments
kozhevn
changed the title
kozhevn
changed the title
kozhevn
changed the title
|
I have a similar issue even as a superuser in the backend adding some "difficult" tags:
Timeout error. |
|
What php version? |
|
PHP 5.6.29 |
|
And yes, downgrading |
|
Call Stack Time Memory Function Location1 0.0001 382696 {main}( ) .../index.php:0 |
This comment was marked as abuse.
This comment was marked as abuse.
|
This should help someone to write a patch:) Example 1: which does not works. Example 2: Links: |
joomla-cms-bot
changed the title
|
I can confirm: |
|
Confirm: StringHelper functions in JFilterInput causes infinite loop for UTF8 content. This is is really big issue, as it breaks basic Joomla functions. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15673. |
|
Issue occours even in backend, if logged in user is in usergroup with Text Filters set to Default Blacklist. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/15673. |
|
I do not get the timeout error (php 5.4.4), but I do get the undefined created_by and modified_by Notices |
|
I get the problem with the following configuration:
Error Message: |
|
Can not confirm.
Have everyone who has the issue saved the plugin "Editor - TinyMCE" because of the warning message, that TinyMCE has been updated? |
|
Did you try it with a (1) "non-administrator user", (2) used UNICODE text (not only English), and (3) the text has a hyperlink? |
|
In my case it occured when using JCE. The issue is highly dependent on article content.
<p style="text-align: justify;"><strong>Nafta nebo baterie? Za nás jednoznačně to druhé. Před pár dny jsme si vyzvedli nový elektromobil. Nyní jej testujeme a zatím můžeme říct jedno - pozor, toto vozítko je vysoce návykové!</strong></p>
<hr id="system-readmore" />
<p style="text-align: justify;"><a href="http://www.example.com" target="_blank" rel="noopener noreferrer">Auta.</a> </p>This will lead to PHP timeout. |
|
@Bilal-Abdeen : Yep, steps reproduced like initial issue post with the content of the textfile "content.txt" and with non-admin user. With the steps reproduced from n3t i can confirm this behaviour. If textfilter for group Manager is set to no filtering there is no timeout error. So it seems to be an issue with the filtering. |
|
@hacki65, |
|
When I save the material typed by the Cyrillic user under the username of the super user, at the end add a lot of characters >> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" << |
|
Concerning the Notices (only) please test #15753 |
Can confirm that my custom plugin using JCE Editor to save large HTML-text reach "Maximum execution time of 120 seconds" when trying to save and update from back-end as Super User. |
|
Does anybody work on that?
|
|
I didn't had the time to dive into this, but a quick feedback on the possible ideas by @csthomas
That's not an option ;) the changes have been made for security reasons, we need proper (=multibyte-aware) code here
Sounds like the best option to me
This would only work with the /u modifer again I guess, because eitherwise we'll run into the same mb-offset issues that we had in the old code |
|
All offsets from preg gives single byte offset but StringHelper::.. think it is multibyte offset - and there is a problem. |
|
There is a nice html validator http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/ |
This comment was marked as abuse.
This comment was marked as abuse.
|
JFilterInput isn't just a validator (actually I don't even know if I'd call that one of its purposes). It's an input filtering system and any good system must be multibyte aware. |
|
@PhilETaylor it looks like it uses some bytecode in preg_* functions to be multibyte aware.... but see @mbabker's comment. |
This comment was marked as abuse.
This comment was marked as abuse.
|
I put it as an example. It is not appropriate time for such changes.
IMO If joomla should use the functions |
|
I've created another PR in the framework using Persian characters following some of the "Fred" cases which also cause the filter to fail, but do not cause the recursion timeout issue. |
|
What about removing invalid utf-8 sequences before removing disallowed tags / attributes? There is a similar things at https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/filter/input.php#L141-L145 |
|
This is also causing issues with JRequest. for example:
With a long string within the request that has UTF8 characters causes issues. Whilst replacing it with JInput it works i.e.: $array = $jinput->getArray(array(), null, 'HTML'); Which we should do anyhow works, the mb_string issue is still a BC. |
|
This is a really huge BC (introduced in Joomla 3.7.0) from Joomla 3.6.5 which broke our website. It broke our homepage - not sure why other people are not experiencing it - maybe some extension? Anyway, as a temporary & ugly fix I had to replace all |
A bug or regression does not automatically equate to a B/C issue. |
|
I do not have any example about security issue in 3.6.5 version.
diff --git a/libraries/joomla/filter/input.php b/libraries/joomla/filter/input.php
index 99fb1d5f48..f7ac2105cb 100644
--- a/libraries/joomla/filter/input.php
+++ b/libraries/joomla/filter/input.php
@@ -144,6 +144,25 @@ class JFilterInput extends InputFilter
$source = $this->stripUSC($source);
}
+ // Workaround for php 5.3
+ if (!defined('ENT_SUBSTITUTE'))
+ {
+ define('ENT_SUBSTITUTE', ENT_IGNORE);
+ }
+
+ // Remove invalid UTF-8 bytes and replace it by U+FFFD
+ if (is_array($source))
+ {
+ foreach ($source as $k => $v)
+ {
+ $source[$k] = htmlspecialchars_decode(htmlspecialchars($v, ENT_SUBSTITUTE, 'UTF-8'));
+ }
+ }
+ else
+ {
+ $source = htmlspecialchars_decode(htmlspecialchars($source, ENT_SUBSTITUTE, 'UTF-8'));
+ }
+
// Handle the type constraint cases
switch (strtoupper($type)) |
|
@csthomas I can't speak to the "security" side. But rather than adding conditionals to Remove invalid utf-8 bytes at the top of just the |
|
The security fix didn't only apply to invalid utf8-bytes but also to valid ones. |
|
@photodude Yes, it should be move to separate method, but I want to show a simple change only, PoC. |
|
@csthomas testing now on the framework from your example code |
|
@csthomas looks like that caused a whole different set of issues. https://travis-ci.org/photodude/filter/jobs/230831070 |
|
Some example text which is breaking the filter that maybe of help when running tests against JFilter Input Clean. |
|
Not sure if this is caused by the same problem, but I am experiencing a similar problem when saving an article on FLEXIcontent, as Super Admin, by just adding a simple HTML table with 15 rows. I get a PHP timeout error: You can see the complete POST request here: https://gist.github.com/lyquix-owner/c8c189a016c3d99c1008059920a87787 System info: @ggppdk - check this |
|
IMO The bug is not directly related to UTF-8 but in UTF-8 it is more visible. The whole |
|
@csthomas I agree cleantags is the issue area |
|
It is as @csthomas says, JFilterInput::escapeAttributeValues() and JFilterInput::cleanTags() are broken because of the new multi-byte code adding byte offsets to character offsets, The infinite loop is caused by JFilterInput::escapeAttributeValues() and the above leads JFilterInput::cleanTags() to continues modify its given string, which results in the infinite loop inside JFilterInput::remove() |
|
I have made a PR here: #15966 |
|
With the PR merged can this issue be closed? |
and others
Steps to reproduce the issue
Backend:
Frontend:
3. Logged in with this user account
4. Edit article (editor doesn't matter), put simple content <h3> test <\h3>
5. As can see 'Save' button works fine, article content updated.
6. Edit again and put the text from attachment content.txt or something another with few html tags.
7. 'Save' button produced timeout error and article updation doesn't happens.
Restoring the file 'libraries/joomla/filter/input.php' to version < 3.7.0 fixes the issue.
Expected result
At the position 7 'Save' button produce fast content updation without error.
Actual result
'Save' button produce timeout error over a time and article updation doesn't happens.
System information (as much as possible)
Additional comments
Behaviour looks like posted in #15628 but issue is another in the reproduction ( can be reproducted only for user and doesn't requred a big content, for me it was happens even with one <p> tag content from example ).
Restoring only the 'libraries/joomla/filter/input.php' to version < 3.7.0 fixes the issue.
Issue happens in frontend only (created user have no backend access).
When superuser edit the article under backend, all works just fine.
It seems looks like as an infinity loop during article content filtration functionality by the 'libraries/joomla/filter/input.php'.
Probably the filtration doesn't happens for superuser under backend.
The text was updated successfully, but these errors were encountered: