That's the expected behavior (security reasons).

Ok I understand this, but is there a way to override it, because in version 3.8.1 it was working.

Yes security reasons,

that assume that the person with privilege to edit custom field's configuration will add malicious code to the value labels text ...

So people privileged with editing configuration of custom fields are not trusted ?

I want to place a link into this custom field, and it will look and act like a link for accepting terms and conditions in registration form. I understand the reasons, but according to the new GDPR regulations there must be a checkbox in the contact form

there must be a checkbox in the contact form

See https://github.com/zero-24/plg_fields_privacycheckbox/releases/latest

So people privileged with editing configuration of custom fields are not trusted ?

Is that a question? If yes, a +1 from me !
I call it "paranoia" that makes com_fields useless in too many cases.

Thank you for the plugin. I will check it, although I wanted to use as few external extensions as possible, and prefer the core Joomla functionalities as custom fields, because they seem like a great tool.

I ... prefer the core Joomla functionalities

The plugin adds an additional field used and handled by com_fields.

(The author @zero-24 of the plugin is a "core Joomla functionality", somehow ;-) )

The security team's decision essentially equated to "this can be used to allow persistent XSS therefore the feature will be restricted for all users and anyone previously using it will have to adapt". So this isn't going to be changed unless you can convince @joomla/security otherwise.

Ok I understand this, but is there a way to override it, because in version 3.8.1 it was working.

That wasn't "working", it was a vulnerability ;)

So people privileged with editing configuration of custom fields are not trusted ?

Exactly. Example scenario: Non Super-Admin user edits a field, put's malicious code in there. Super-Admin opens article, code gets executed and upgrades the non-super-admins user level.

@SniperSister

Is it possible to do have safe filtering according to "Text filters" ?
or is it possible to use a "Safe HTML" filtering ?

or the above will not work ?

That would at least fix the JS issue

It's problematic because effectively the filtering for an item matches the lowest ACL level's filtering.

Suppose authors are not allowed to put HTML into checkboxes but super users are. Super user configures form, author modifies it, HTML is lost.

That problematic applies to articles too, right @mbabker

Suppose authors are not allowed to put HTML into checkboxes but super users are. Super user configures form, author modifies it, HTML is lost.

yes, the above is true in the general case
but not in this case

-- i mean the labels are not posted by the the forms using custom fields, the values of are posted

in this case we are taking about allowing HTML in the labels
not about allowing HTML in the values of the checkbox(es)

It applies anywhere someone might be using that filtering config. Some of the other fields plugins seem to be using that filtering helper, com_content does so, looks like one of the fields in module manager too.

The main point I want to make sure is understood is that even if you do use that API, people putting in content can only do so matching the minimum filtering level allowed, even if their permissions are higher because a lesser privileged user can mess up your content.

in this case we are taking about allowing HTML in the labels

HTML allows <script> tags. The use of <script> tags is what enables these types of vulnerabilities to be executed. It has nothing to do with the field's value, it's everything to do with the presentation aspect.

HTML allows <script> tags. The use of <script> tags is what enables these types of vulnerabilities to be executed. It has nothing to do with the field's value, it's everything to do with the presentation aspect

ok that is why i said above to do filtering according to "Text filters"

and if the above is not good enough then do this:

1. filter by "Safe HTML" filter
2. and then also filter by configured "Text filters" (in case the text filters of a user are more strict)

I understand that if a "lesser" user edits the configuration of the field some HTML maybe lost but this applies everywhere "Text filters" are used and 2 different people can edit a record

The component helper's filterText method already works in the way you describe (which is exactly why it is the callback method used everywhere)...

I am not sure that i understand you

... filter="JComponentHelper::filterText" ...

The above will use the configured "Text filters" for the current user
if in a usergroup one configured to use
-- custom blacklist
-- whitelist
-- no filtering

then with appropriate settings in the above,
you can save <script> Tag

That is why i spoke of
-- filter by "Safe HTML" filter + filter by configured "Text filters" (JComponentHelper::filterText)

So the above filtering is not good enough ?

You either use the generic "safe HTML" option that various fields have, or you use the advanced filtering logic exposed through the component helper. Don't do both.

The plugin for privacy checkbox is very useful. The only issue, that I am facing is that (and this is only if the problem is not my own incompetence :D ) after a privacy checkbox field is created and a text with script tags is placed in Checkbox Note and the contact form is ready for sending messages, then when I tested it, in the received e-mail, there is only a row with checkbox filed name (this is the label of the checkbox), but there is no value and text for this field - basically the Checkbox note text is not in the email. I have placed and issue in here

after a privacy checkbox field is created and a text with script tags is placed in Checkbox Note

just for the record just a tags (== links) are allowed no script tag at all :)

I think we can close this one here than? @Porscha-joomla ?

just for the record just a tags (== links) are allowed no script tag at all :)

Yes I know, I read that in your description, I have a link tag too :)

And again yes, I think we can close this.

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

closed as stated above.