| Yurik | |
| Jan 13 2017, 8:24 AM |
| F5279742: pasted_file | |
| Jan 13 2017, 8:28 AM |
https://www.mediawiki.org/wiki/User:Yurik/Bug155216
<mapframe width=500 height=500 latitude=-34 longitude=151 zoom=12>
[{
"type": "ExternalData",
"service": "page",
"title": "Sandbox/Gareth/T7 Olympic Park Line.map"
},
{
"type": "ExternalData",
"service": "page",
"title": "Sandbox/Gareth/T6 Carlingford Line.map"
}]
</mapframe>| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T155601 Stabilizing Interactive Products | |||
| Resolved | MaxSem | T155216 Wikimarkup is shown as raw text instead of html on marker click for externaldata page |
Question: on which wiki should the wikitext be parsed? Links point to different pages on different wikis, and in Yuri's example some links that attempt to work this around by setting an explicit interwiki prefix might be just rendered as bold text without any linking, depending on which wiki is local: c: on Commons, w: on Wikipedia.
tl;dr: Parse the wikitect on Commons.
Here's my full thinking and rationale.
Tabular datasets allow the messages to be localised. So, you could have a message in French which is automatically shown on French sites, an English description which is automatically shown on English sites, and so on. The difficulty is, how wikitext is parsed is dependent on the wiki that the wikitext is parsed on even if the language is the same; the French Wikipedia might have radically different output from the French Wiktionary, for example. Basically, when trying to locally parse this wikitext, all bets are off; this could cause wild and unpredictable behaviour no matter which way you try to do it.
Given the above, we need to parse the wikitext centrally. This causes the output to be the most consistent and most predictable. This would obviously still allow different messages for different languages. Some additional care would have to be taken by users when writing their descriptions so that they make sense on all wikis.
Change 351522 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/Kartographer@master] SECURITY: fix XSS in map feature title/description via tabular data
Change 351523 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/JsonConfig@master] SECURITY: fix XSS in map feature title/description
Change 351523 merged by jenkins-bot:
[mediawiki/extensions/JsonConfig@master] SECURITY: fix XSS in map feature title/description
Change 351522 merged by jenkins-bot:
[mediawiki/extensions/Kartographer@master] SECURITY: fix XSS in map feature title/description via tabular data
Change 351536 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/JsonConfig@REL1_29] SECURITY: fix XSS in map feature title/description
Change 351538 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/Kartographer@REL1_29] SECURITY: fix XSS in map feature title/description via tabular data
Change 351536 merged by jenkins-bot:
[mediawiki/extensions/JsonConfig@REL1_29] SECURITY: fix XSS in map feature title/description
Change 351538 merged by jenkins-bot:
[mediawiki/extensions/Kartographer@REL1_29] SECURITY: fix XSS in map feature title/description via tabular data
Change 351916 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/Kartographer@wmf/1.29.0-wmf.21] SECURITY: fix XSS in map feature title/description via tabular data
Change 351916 merged by jenkins-bot:
[mediawiki/extensions/Kartographer@wmf/1.29.0-wmf.21] SECURITY: fix XSS in map feature title/description via tabular data
Change 351919 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/extensions/JsonConfig@wmf/1.29.0-wmf.21] SECURITY: fix XSS in map feature title/description
Change 351919 merged by jenkins-bot:
[mediawiki/extensions/JsonConfig@wmf/1.29.0-wmf.21] SECURITY: fix XSS in map feature title/description
Change 352285 had a related patch set uploaded (by Gergő Tisza; owner: MaxSem):
[mediawiki/extensions/JsonConfig@master] Parse map data on central wiki
This bug is partially fixed. Due to the security fix above, the text is now parsed on client wikis. One can see that this is not what we decided to do above, but it was necessary as part of the security fixes.
The solution that @MaxSem proposed above for parsing on central wikis is not without its problems. Max is going to talk to @EBernhardson about this and get his opinion. We can decide what to do then.