Problem/Motivation

In some cases, the texfields do not allow all content you want to enter. The example (and possibly only relevant case) I ran into is the feature security header, that can become a very long list of features.

In addition, it can be very hard to check multiple fields at once for similar entries.

Proposed resolution

One proposal was to change the fields to text areas. Especially for the feature security, it might be good to have separate input fields for all possible features, although that would be quite a UX challenge. Would we also need to cater for entering your own features? Or make that a configuration in itself, the offered features in the form..?

Remaining tasks

* Reach concencus.
* Write patch
* Review

User interface changes

The input fields would be changed somehow, to make them more easily inspectable and in case of feature security, allow any input desired.

API changes

None.

Data model changes

Especially the proposed change for feature security would require a different way of storing the configuration.

Original report by dunx

It's very hard to check multiple fields at once for similar entries. Can the majority of fields be changed to use ?

CommentFileSizeAuthor
#8 3340072-8.patch14.31 KBmcdruid
#6 3340072-6.patch14.32 KBmcdruid
#6 interdiff-3340072-3-6.txt2.95 KBmcdruid
#3 seckit-3340072-field-text-lengths-3.patch11.3 KBpenyaskito

Comments

penyaskito created an issue. See original summary.

penyaskito’s picture

penyaskito
he/him
Primary language Spanish
Location 🧑🏽‍🌾 Seville 💃 Andalusia, UTC+2 🇪🇺
commented
Status: Fixed » Active
penyaskito’s picture

penyaskito
he/him
Primary language Spanish
Location 🧑🏽‍🌾 Seville 💃 Andalusia, UTC+2 🇪🇺
commented
Status: Active » Needs review
StatusFileSize
new seckit-3340072-field-text-lengths-3.patch11.3 KB

Attached patch with tests, similar to what was done in 7.x-1.x

mcdruid credited dennis_meuwissen.

mcdruid’s picture

mcdruid commented

Adding credit from #3083534: Extend length of feature policy field which I've closed as a duplicate.

mcdruid’s picture

mcdruid commented
StatusFileSize
new interdiff-3340072-3-6.txt2.95 KB
new 3340072-6.patch14.32 KB

A couple of textfields had been missed, plus added a CSS library to match what we did in the D7 branch.

In the process of adding the CSS library, I think I've found that this library is defined incorrectly:

modules/contrib/seckit$ head -n3 seckit.libraries.yml 
seckit/listener:
  js:
    js/seckit.listener.js: {}

... I don't think it should have the module name prepended to the library name. That's one for a follow-up issue though.

mcdruid’s picture

mcdruid commented

#3377694: seckit/listener library incorrectly defined for the JS listener library fix.

mcdruid’s picture

mcdruid commented
StatusFileSize
new 3340072-8.patch14.31 KB

Fix for the JS library meant this patch needed the tiniest of re-rolls.

  • mcdruid committed ff1433c4 on 2.x 
    Issue #3340072 by mcdruid, penyaskito, dennis_meuwissen: Text fields not...
mcdruid’s picture

mcdruid commented
Status: Needs review » Fixed

Thank you everyone that contributed.

mcdruid credited Dylan Donkersgoed.

mcdruid credited Rajeshreeputra.

mcdruid’s picture

mcdruid commented

Adding credit from #3306932: Allow entering more content in CSP fields which I've closed as a dupe (hope it's not too late to add the credit).

mcdruid credited ashetkar.

mcdruid’s picture

mcdruid commented

Adding credit from another duplicate #3302563: Add textarea type to script-src field.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

floris vedder’s picture

floris vedder commented

I found that this patch can result in a 502 error due to a to large response header.

So use it with care.

To big header issue

When the response header is to large the server will return a 502 and will log something like: upstream sent too big header while reading response header from upstream, client

Possible solution:

Validation before saving as done on another platform.
https://really-simple-ssl.com/instructions/content-security-policy-maxim....
As stated they first check the impact of the content security policy configuration against the server configuration before saving.

Combination with downloads:
When the configuration is just below the maximum it will work on normal pages but in our case resulted still in the `to big header` issue on downloads. Probably due to additional header info in a download like mime-type. Is the Content-Security-Policy really needed on a download? Otherwise the solution might be to not include it in the header in downloads.