Contao: Fehlende URL-Kodierung von {{file::UUID}} Inserttag

[Mynyx]

Bei der Ausgabe des {{file::UUID}} Inserttag erfolgt keine URL-Kodierung, beispielsweise wenn der Pfad ein Leerzeichen enthält.

[aschempp]

Eine automatische URL-Kodierung kann nicht stattfinden, das System kann nicht wissen ob du das benötigst. Mit {{file::UUID|urlencode}} solltest du das selber machen können.

[fritzmg]

Würde nicht urlencode auch die slashes encoden?

[aschempp]

Möglich, dann wäre wohl eine anderes Flag richtig Aber von Beginn weg encodieren ist auf jeden Fall falsch.
https://docs.contao.org/manual/de/artikelverwaltung/insert-tags/#insert-tag-flags

[Mynyx]

Eine automatische URL-Kodierung kann nicht stattfinden, das System kann nicht wissen ob du das benötigst. Mit {{file::UUID|urlencode}} solltest du das selber machen können.

Das {{file::UUID}} Inserttag wird auch vom Picker eingefügt. Es muss vorausgesetzt werden können, dass automatisch eine valide URL erzeugt wird.

[leofeyer]

Ich halte das schon für ein valides Issue. Zumindest sollten wir es mal mit den @contao/developers besprechen.

[aschempp]

Ja im TinyMCE Picker sollte ein entsprechendes Flag hinzugefügt werden. Aber der InsertTag kann auch für etwas benutzt werden dass keine Encodierung will, Output-Encoding ist immer Kontext-abhängig!

[Mynyx]

Der Picker mit Inserttag-Ausgabe wird nicht nur im TinyMCE verwendet.

Bereits vorhandene Inserttags müssten dann auch automatisch im Rahmen eines Updates angepasst werden.

[leofeyer]

Es geht ja auch nicht um Output-Encoding, sondern um URL-Encoding. Und da wäre es IMHO schon korrekt, wenn %20 anstatt im Quelltext steht.

[ausi]

Ich denke {{file::UUID}} ist dafür gedacht die URL zu der Datei auszugeben (deshalb wird es auch von den Pickern verwendet) und somit sollte der Pfad auch korrekt URL-encoded werden.

[leofeyer]

@aschempp hat doch Recht damit, dass wir den Pfad nicht standardmäßig enkodieren dürfen, da man ihn sonst nicht mehr lesbar im HTML ausgeben kann. Beispiel:

<figure>
    <img src="{{file::084287e8-d403-11e9-b8be-b8098abe7f19}}" alt>
    <figcaption>{{file::084287e8-d403-11e9-b8be-b8098abe7f19}}</figcaption>
</figure>

Die Bildunterschrift wäre dann files%2Fpublic%2Fthis%20is%20an%20image.jpg anstatt files/public/this is an image.jpg und der Anwender hätte keine Möglichkeit mehr, die Ausgabe zu korrigieren, weil es aus Sicherheitsgründen kein rawurldecode-Flag gibt.

[fritzmg]

Die vom URL picker zurück gegebene URL wäre dann aber nun weiterhin "falsch"?

[Toflar]

Ab der 4.8 könnten wir das theoretisch fixen. Da lässt sich der generierte InsertTag ja beeinflussen dank meines PRs.

[leofeyer]

Das ganze ist eh nur ein theoretisches Problem, weil der Picker ja auch so funktioniert, oder?

[fritzmg]

Es geht ja um die URL, die im Frontend generiert wird. Die hat dann bspw. spaces statt %20.

[leofeyer]

Die URL, die wo genau im Frontend generiert wird?

[fritzmg]

Die URL, die wo genau im Frontend generiert wird?

<div class="ce_hyperlink first block">
  <a href="files/folder with spaces/file with spaces and &.jpg" class="hyperlink_txt" title="">files/folder with spaces/file with spaces and &.jpg</a>
</div>

[leofeyer]

Aber der Link funktioniert ja trotzdem, oder?

[fritzmg]

Ja :). Ich weiß nicht, ob es einen Browser gibt, der damit tatsächlich nicht klar kommt. Laut HTML Validator wäre es aber ein Fehler:

Das & ist dem Validator interessanterweise egal, wird aber vom Browser als Fehler markiert:

[leofeyer]

Ja, da müssten wir wohl ein ampersand() ergänzen. Ich schau es mir nochmal genau an.

[fritzmg]

Aber nur per flag - weil der Insert Tag könnte ja an Stellen eingesetzt werden, wo keine HTML entities sein können/dürfen.

[ausi]

Wer nutzt {{file::UUID}} als Bildunterschrift? IMO sollte es im Standardfall eine valide URL sein.

Wie wäre es mit weiteren Optionen?

| | |
|-----------------------------|------------------------|
| {{file::UUID}} | folder/file%20name.jpg |
| {{file::UUID:url}} | folder/file%20name.jpg |
| {{file::UUID:path}} | folder/file name.jpg |
| {{file::UUID:name}} | file name.jpg |
| {{file::UUID:meta:caption}} | Caption Text |

Oder wäre die korrekte schreibweise {{file_url::}}, {{file_path::}} usw?

So könnte man jedenfalls andere Use-Cases abdecken und {{file::UUID}} selbst beheben damit immer eine valide URL dabei rauskommt.

[leofeyer]

Vermutlich eher file_url::UUID als file::UUID:url. Aber wir können den Standardfall nicht ohne BC-Break ändern.

[ausi]

Aber wir können den Standardfall nicht ohne BC-Break ändern.

Ich denke dass jemand {{file::UUID}} nicht als URL eingesetzt hat ist äußerst selten. Wenn jemand den Insert-Tag tatsächlich als Text verwendet, wäre der BC-Break kein großes Problem denke ich da der Text ja weiterhin lesbar bleibt.

[Toflar]

Ich bin auch der Meinung, dass der Standardfall wohl encoded sein sollte.

[leofeyer]

Wie am 28. November auf Mumble besprochen, soll die Ausgabe standardmäßig URL-kodiert werden (System::urlEncode()).

[leofeyer]

Siehe #1268.