And more importantly: how can i get a string like 'string>passed>ok' using JInput if getString is no more usable?

This could lead to unexpected results because characters '<' and '>' included in a string can't get saved anymore when using getString().

Looking at the last changes in JFilterInput, this case works fine at 685f55e but is broken at 495dcc7

Unless there is some necessity for the added filtering, this is not only a bug, but a release blocker.

// @rdeutz

We have experimented issues especially when using getString for tokens such as OAuth, etc
If the string contains a '>' or '<' now it gets stripped out and things don't work anymore.

But obviously this impacts everywhere, even when saving an article title or 'Meta description' field.

@csthomas Plese check this also.

Merge this issue to the 3.7.3 branch please.

@joeforjoomla only PR can be based on a branch. I have created unit tests so that we can see we a code change passes. #16816

Thanks @rdeutz ... sorry for my ignorance

All good we all are learning constantly :-)

:) that's true

Did all these cases pass before? Like I'm pretty sure that one of these cases is a "known failure" for ages (see my 18 month old issue at joomla-framework/filter#15)

If I revert 495dcc7 a string like "string>passed>ok" is working fine, with my added test cases we have 28 errors without revert and 21 after revert.

My PR changed that.
character > now is removed but previous was not
< was always removed (previous too) and the first or more words followed, example for tests ala < ma kota >
or ala > < ma kota

Method getString and getHtml works very similar.
getString additional replaces all html entities to utf8 encoded characters.

They use the same cleanTags() method and tries to return valid html code.

For me there is some misunderstanding with getString(), because it validates source as html code.

Now getString() tries to remove forbidden tags and html attributes.
Can someone explain me what should be the difference between getString and getHtml?

I think part of the problem is it's arbitrarily treating < and > as HTML tag indicators and not accounting for a scenario where the brackets may be used in other contexts. So I don't think we can arbitrarily just say "if you know your string may contain these characters, you cannot use the string filter"; they are not exclusive to HTML output.

I think that both < and > should never be removed by an arbitrary string using getString. They are 2 normal characters in a generic string context after all, no reason to remove them.
It would be more logical to remove them in a getHtml method because they could be recognized as invalid HTML markup.

Reference this PR #16842

closed as having PR #16842

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/16812