Page MenuHomePhabricator

Links from embedded functions don't render properly
Open, In Progress, HighPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What happens?:
Displays

<a href="https://www.wikifunctions.org">Link to main page

What should have happened instead?:
Should show a link

It is embedding the following function, and the result looks reasonable:
https://www.wikifunctions.org/view/en/Z28904

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

Event Timeline

cmassaro moved this task from To Triage to Product Backlog on the Abstract Wikipedia team board.

Change #1218312 had a related patch set uploaded (by Genoveva Galarza; author: Genoveva Galarza):

[mediawiki/extensions/WikiLambda@master] Set correct logger for on-client sanitiser, and rise log levels to info

https://gerrit.wikimedia.org/r/1218312

Only when the url matches the current host, given by MediaWikiServices::getInstance()->getMainConfig()->get( 'Server' ) it should render a link
In this case, it should match, because the function hardcodes www.wikifunctions.org, which should match the server name. However, it's acting as if it were a different host.

I'm changing the log levels so that we can inspect what's happening and see what is the content of allowedUrls.

Change #1218312 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Set correct logger for on-client sanitiser, and rise log levels to info

https://gerrit.wikimedia.org/r/1218312

My guess would be that the url set is either to https://www.wikifunctions.org or http://wikifunctions.org or something with an extra slash like https://wikifunctions.org/. So perhaps a mismatch with http/https and www/non www or such.
Or the server is set to something else/nothing of course. let the logging show us!

That seems to be the case, with the implementation rendering the link with relative protocol:

<a href="//www.wikifunctions.org">

The fragment sanitizer renders whole links. See https://www.wikifunctions.org/wiki/User:Geno_(WMF)/Sandbox

Knowing this, I'll make a patch to ignore protocol

Looking a bit more into this, when setting an url to current server, we need to match the value in the global.server configuration. We can look at it here:

For wikifunctions: https://www.wikifunctions.org/w/api.php?action=query&meta=siteinfo&siprop=general&format=json

{
    "batchcomplete": "",
    "query": {
        "general": {
            ...
            "server": "//www.wikifunctions.org",

or for en.wiktionary: https://en.wiktionary.org/w/api.php?action=query&meta=siteinfo&siprop=general&format=json

{
    "batchcomplete": "",
    "query": {
        "general": {
            ...
            "server": "//en.wiktionary.org",

So implementations should use protocol-relative links.


However, our sanitizer should also allow creating urls to other pages in SiteMatrix, and there server urls set with https://

See: https://www.wikifunctions.org/w/api.php?action=sitematrix

This means that the https://www.wikifunctions.org url should have probably worked. I'll be poking at this a bit more and see why it didn't.

Change #1219652 had a related patch set uploaded (by Genoveva Galarza; author: Genoveva Galarza):

[mediawiki/extensions/WikiLambda@master] PFragmentSanitiser: compare allowedUrls using relative protocol domains

https://gerrit.wikimedia.org/r/1219652

Good finds. I think we shouldn't force users to have to know the complexity of having non protocol links. Perhaps its better to strip http(s) off in that case.
But apart from that since https://www.wikifunctions.org is indeed in the sitematrix , it should have just worked. (maybe something is escaped somewhere? this is me guessing) very strange indeed

Change #1219652 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] PFragmentSanitiser: compare allowedUrls using relative protocol domains

https://gerrit.wikimedia.org/r/1219652

Jdforrester-WMF subscribed.

This has now gone live in production with the MediaWiki train; please check and confirm if it's fixed the issue.