Page MenuHomePhabricator

VE seems to be able to "add" links to files that are (probably) stored on the editor's local hard drive
Closed, ResolvedPublic8 Story Points

Description

In this Hebrew Wikipedia edit, multiple files (קובץ namespace is "File") were added, and the URL is actually a local Windows-style path: C:/Users, etc.

This shouldn't be possible.

Event Timeline

Amire80 created this task.Jun 29 2016, 3:22 PM
Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJun 29 2016, 3:22 PM

Your link takes me to 'Bad title'.

Looks like the page has been deleted.

Looks like the page has been deleted.

Heh.

Moved to Draft space, and that diff has been deleted, but as long as it's in Draft there's no reason to have the revisions deleted, so I restored them. The link works now.

And another example:

https://he.wikipedia.org/w/index.php?title=%D7%A4%D7%A8%D7%A0%D7%A6%D7%99%D7%A1%D7%A7%D7%95%D7%A1_%D7%9E%D7%90%D7%A1%D7%99%D7%96%D7%99&type=revision&diff=19005587&oldid=18984047

Search for "C:/Users". It appears many times.

Sorry it's all from the Hebrew Wikipedia—that's the one in which I happen to examine weird edits most carefully ;)

This could be just users pasting these into the link dialog and expecting them to work, not realizing that the URL refers to something on their computer only. URLs like file:/// appear on Windows when you open something using the web browser, and file:///C:/Users/bars/Desktop/פרנציסקוס הקדוש מאסיזי ויקיפדיה.docx is technically a valid MediaWiki page name, with file being normalized to קובץ in Hebrew.

This is quite possible, but file:/// links are probably not useful in any case. (Maybe on some Intranet MediaWiki installations, but certainly not on a Wikimedia site.) The three slashes should... sound an alarm of some kind, even if they are technically valid.

DLynch added a subscriber: DLynch.Jul 25 2016, 7:07 PM

Just to confirm, pasting the link into the link inspector considers it valid, so it's not implausible that this is how it's happening.

I don't think we currently have a way to signify "this _is_ valid, but might not mean what you want it to" in that inspector.

I think what happens is that we only switch to the external link tab if the protocol matches the list of allowed protocols in MW. What we should do is switch to external for any protocol, then validate the input against the allowed list, so typing file:// will come up as invalid, but it would soil be possible to switch to internal

I think what happens is that we only switch to the external link tab if the protocol matches the list of allowed protocols in MW. What we should do is switch to external for any protocol, then validate the input against the allowed list, so typing file:// will come up as invalid, but it would soil be possible to switch to internal

Yeah, that works; if you really really do want to create the wiki article file:///foo you still could, by switching back to 'search pages'.

Change 301005 had a related patch set uploaded (by DLynch):
MWLinkAnnotationInspector: switch to external tab on any schema

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

DLynch claimed this task.Jul 25 2016, 9:44 PM

Change 301005 merged by jenkins-bot:
MWLinkAnnotationInspector: switch to external tab on any schema

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

See FIXME comment on above patch.

Change 301629 had a related patch set uploaded (by DLynch):
MWLinkAnnotationInspector: change where auto switch to external occurs

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

Change 301629 merged by jenkins-bot:
MWLinkAnnotationInspector: change where auto switch to external occurs

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

Jdforrester-WMF closed this task as Resolved.Jul 29 2016, 5:00 PM
Jdforrester-WMF triaged this task as Normal priority.
Jdforrester-WMF moved this task from To Triage to TR0: Interrupt on the VisualEditor board.
Jdforrester-WMF set the point value for this task to 8.