Page MenuHomePhabricator

Clicking on non-existing image link does not redirect to upload anymore
Open, MediumPublic

Description

Author: burobjorn

Description:
Problem description:
We have a wiki with lots of article's containing links to not yet existing images. In this articles the links to this not yet existing images are used to upload images. This makes it fairly easy to quickly add an image to a specific article. Before version 1.16.3 the editors would click such a link and they would be redirected to the upload form. Since 1.16.3 this does not work anymore.

The reason why this doesn't work anymore is due to the recommended rewrite rules to prevent IE6 XSS attacks suggested in 1.16.3 and 1.16.4 (see also bug #28235 https://bugzilla.wikimedia.org/show_bug.cgi?id=28235).

Reproduction of the issue (tested in 1.16.4):
Remove the recommended rewrite rules from Apache, restart Apache and click on a link of a not yet uploaded image. You will be redirected to the upload form.

Would be great if the original feature could be restored. Any clues on how to achieve this? Contact me for more info. I'm more than willing to help solve this.

Thanks for all the great work on Mediawiki!


Version: 1.22.0
Severity: normal

Details

Reference
bz28891

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:25 PM
bzimport set Reference to bz28891.
bzimport added a subscriber: Unknown Object (MLST).
TheDJ added a comment.May 9 2011, 7:26 PM

For clarity, were these external links, or [[File:image.jpg]] internal links ?

burobjorn wrote:

Internal links.

brion added a comment.May 9 2011, 9:16 PM

A few things to check:

  • what exactly is the form of the URLs for those links?
  • what exactly do you see when you click one of those links? Error messages, redirects, etc should be described in detail.
  • what exactly are the rewrite rules you're using?
brion added a comment.May 9 2011, 11:26 PM

Per triage meeting notes we think this is related to the new checks, and is probably striking mostly on IE users (?) Attaching to bug 28840 as related.

burobjorn wrote:

@brion: I have tested this with Chromium 11.0.696.65 (84435) Ubuntu 10.04 and Firefox so my guess would be that this is not related to the browser.

As for your other questions:

  1. what exactly is the form of the URLs for those links?

The type of links we have look like this in the wiki text:

Bestand:Kimvankooten.png

This results in an url which looks like this:

http://www.beeldengeluidwiki.nl/index.php?title=Speciaal:Uploaden&wpDestFile=Kimvankooten.png

This is a public wiki so you may also check this link live.

  1. what exactly do you see when you click one of those links? Error messages,

redirects, etc should be described in detail.

You'll see a 403 Forbidden message from Apache which is exactly what it should do according to the Rewrite Rules in Apache's config.

  1. what exactly are the rewrite rules you're using?

RewriteEngine On
RewriteCond %{QUERY_STRING} \.[a-z0-9]{1,4}(#|\?|$) [nocase]
RewriteRule . - [forbidden]

Thanks for the quick response on this ticket! Let me know what I can do to help fix this issue.

Created a test page on https://translatewiki.net/wiki/User:Siebrand/bug28891

Contents are:

[[File:Doesnotexist.jpg]] - goes to upload form

[[:File:Doesnotexist.jpg]] - goes to edit mode of image page

[[Media:Doesnotexist.jpg]] - goes to upload form

Should this be a support issue on mediawiki.org instead of a bug marked as regression?

(In reply to comment #6)

Should this be a support issue on mediawiki.org instead of a bug marked as
regression?

Sounds like documentation/support, to me.

Have to bump up this older Bug report (which is a serious problem as many file redirects are broken - showing up as red links and redirecting to upload form).

http://commons.wikimedia.org/wiki/User:Rotatebot/Log (Version of 21:15h UTC) has some entries now displayed as redlink, such as image file links to http://commons.wikimedia.org/wiki/File:Russian_Imperial_Navy_rear-admiral_shoulder.png

The files (set to display as thumb, File:xxx|thumb) are not displayed, instead the link is a redlink to http://commons.wikimedia.org/w/index.php?title=Special:Upload&wpDestFile=Russian_Imperial_Navy_rear-admiral_shoulder.png

The upload page does not show any sign of a previous movement nor that a redirect is existing.

File usage at http://it.wikipedia.org/wiki/Vladimir_Istomin (in infobox) is broken as well (redlink to local upload page).

Rotatebot Log page also uses :File:xxx and this link is shown in blue, clicking on it opens the file page and the redirect is working there.

This example given above may be cured in some hours if Commons Delinker replaced the images but it's the siftwareproblem that's still around (especially for cases with Delinker unable to replace usages)

Comment 6 is still valid.

Denniss: This bug report is about not going to the Upload page for non-existing files. If I get it right, your bug is about going the Upload page not showing a hint that a file with the proposed name already exists, due to some other bug that makes the Rotatebot not show images in some cases. That sounds different.

I attached this report to a bug that sounded similar but I may have hit the wrong one.

The problem is, redirected images do either not show up at all or only after a long period of time. Inbetween these two options pages linking to the images (in a normal way, i.e to view this image) only show a redlink which points to the upload page.

Now, some 12+ hours later, the redirects in the example from Rotatebot log seem to work although the upload page still shows no sign of an existing page. I assume it pops an error if one tries to upload an image on top of the redirect (not tested).

I'm not that familar with bugzilla so if you have an idea for a better placement of the report feel free to instruct me how to do this or split the report into a separate one.

Restricted Application added subscribers: Steinsplitter, Matanya, Aklapper. · View Herald TranscriptAug 9 2015, 9:01 AM
Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:33 PM