Last modified: 2014-11-18 12:09:19 UTC
The media selector (both in WikiEditor and Visual Editor) does not find local images in a private wiki. When the same wiki is set to public, it works. I've tried this with 3 different installations (1.22 and 1.23wmf20) on two different servers, both with Visual Editor and WikiEditor. The relevant setting is $wgGroupPermissions['*']['read'] = false; When this is set to false, when a user (logged in and registered) edits a page and starts typing the name of an existing file in the media selector, the input box remains empty and does not suggest existing file names. When the read permission is set to true, then it works as expected (giving a list of suggestions in the input box) - but of course then the wiki is no longer private. On the other hand, the link selector finds the files when I type "File:Filename..". Also, the image is actually shown in the article when I insert it with Wiki markup, or when I type in the correct filename in the selector and click on "insert". So somehow the media selector (but not the link selector) does not understand the permission correctly for a logged-in user.
Maybe private only wikis cause api to be disabled.
(In reply to Bawolff (Brian Wolff) from comment #1) > Maybe private only wikis cause api to be disabled. API is not disabled completely. All other API calls seem to work, only image search is affected. The following workaround in LocalSettings.php also works: if ( strpos($_SERVER['REQUEST_URI'], "prop=imageinfo") > 0 ) { $wgGroupPermissions['*']['read'] = true; } This disables read protection selectively for the image search.
(In reply to Stephan Matthiesen from comment #2) > (In reply to Bawolff (Brian Wolff) from comment #1) > > Maybe private only wikis cause api to be disabled. > > API is not disabled completely. All other API calls seem to work, only image > search is affected. > > The following workaround in LocalSettings.php also works: > > if ( strpos($_SERVER['REQUEST_URI'], "prop=imageinfo") > 0 ) { > $wgGroupPermissions['*']['read'] = true; > } > > This disables read protection selectively for the image search. Actually that can be exploited to get around read protection everywhere (including normal web requests). Any url can have that string in it.
(In reply to Bawolff (Brian Wolff) from comment #3) > Actually that can be exploited to get around read protection everywhere > (including normal web requests). Any url can have that string in it. Of course, and I don't recommend it. It was just meant as an indication that it's a bug in this specific api call for image searches and that other api calls are ok, so it's not a disabled api.
Hello there, I just face this issue in my installation. There are any news about solution for this? In time. Thank you Stephan for the workaround. []s
In 1.25wmf8, it works now correctly without the (unsecure) workaround. I guess some other things with permissions were fixed which solved this one as a side effect too.
