Validierung Link-Adresse Seitentyp Externe Weiterleitung

[Mynyx]

Bei der Validierung der Link-Adresse einer Seite vom Typ Externe Weiterleitung werden Links die mit // beginnen (z. B. //www.google.de) sowie Links die nur auf einen Anker verweisen (z. B. #test) als ungültig zurückgewiesen.

Dabei wird die eingegebene Adresse außerdem gelöscht und die Fehlermeldung Bitte füllen Sie das Feld "Link-Adresse" aus! angezeigt, statt die Eingabe wie üblich zusammen mit einer spezifischen Fehlermeldung anzuzeigen.

[fritzmg]

#test not being valid for an external URL is normal.

However you are right that the validation should not simply remove the URL altogether and it should display an appropriate error message.

[Mynyx]

Unfortunately, it is not possible to specify an anchor for an internal forwarding, it would of course be preferable to add an anchor option there.

[fritzmg]

Even if you were able to set an anchor there, it would not work in the front end because of the <base href="…"> (except on the index page). You need to set it to {{env::request}}#test (and this should be possible for the target in an external redirect page).

[aschempp]

You can use an anchor, but you need to add a valid url (potentially to the current page, using an insert tag).

[KaiserCh]

Should an URL starting with // be invalid at all? While you cannot enter this notation into the browser bar (will result in file://URL), it seems to work in . Browsers will interpret the // as the protocol currently in use, so its either HTTP or HTTPS.

[aschempp]

That is technically correct. However, be aware that protocol-relative URLs are deprecated. If a site is available via HTTPS, you should ALWAYS link to the secure URL.

[Mynyx]

@KaiserCh I think you mean \\ that is interpreted as file://, because // works fine.

[KaiserCh]

Not in GNU/Linux, where / is the regular path separator. And since MacOS is an Unix and Android a Linux, both should act the same as my Ubuntu desktop.

[leofeyer]

It is actually the PHP parse_url() function which does not handle the protocol relative URL. Of course, we could work around this issue but since @aschempp already explained that protocol relative URLs are deprecated, I don't think we should.