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.

gabriel_stelmach wrote:

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.

I still have the same problem in version 1.25wmf17 (rMWd70b7512acb9)
e.g. typing "l" shows only two images, adding an "e" shows only one, other(!) image.
In order to find a file, I have to enter the complete name, including the extension :-(
Even worse, some files cannot be found at all. They can only be inserted using the text-editor.
I cannot find the file "At_venice.jpg". The file appears as "At_venice.jpg" in the images-directory, but as "At venice" on the wiki-page describing the image.
Anyway, I can't find the file Koala.jpg either, no spaces or underscores there :-( (but a capital letter...)

Still the same issues as described earlier: I can find the file "test_lego.jpg" by typing "test", but not by typing "lego".

It's getting better: I upload a file as "jorun.jpg" but cannot find it, unless by typing the complete name. I upload the same file as "jorun test.jpg". I can find this photo by typing 'jorun'.

Still looks like a bug to me!

I've got the same problem (on a private wiki).

I've tryed the permission fix. Still no effect on the first glance.

However, If i type "*" or the complete name (including the namespace), it finds my image, if I type the only the name (or a part of the name) nothing appears.

This seems to be an issue with the MediaWiki API. It's search algorithm is so strict, that you already need to know the exact name in order to get a result.

Appending / prepending an astericks helps, though. Maybe VE should do that by default?

VisualEditor-REL1_25
MediaWiki 1.25.1
PHP 5.5.9-1ubuntu4.9 (apache2handler)

Presumably some permission is missing. Can you post the exact API requests and responses?

Yes, this is the API request that fails to find the image:

api.php?callback=jQuery1113038504008506424725_1437475882811&action=query&format=json&iiurlheight=200&generator=search&gsrnamespace=6&continue=&iiprop=dimensions%7Curl%7Cmediatype%7Cextmetadata%7Ctimestamp&prop=imageinfo&gsrsearch=Server&iiurlwidth=300&gsroffset=0&gsrlimit=30

It results in:

/**/jQuery1113038504008506424725_1437475882811({"batchcomplete":""})

If I add an astericks at the end of the search-term, it works:

api.php?callback=jQuery1113038504008506424725_1437475882811&action=query&format=json&iiurlheight=200&generator=search&gsrnamespace=6&continue=&iiprop=dimensions%7Curl%7Cmediatype%7Cextmetadata%7Ctimestamp&prop=imageinfo&gsrsearch=Server*&iiurlwidth=300&gsroffset=0&gsrlimit=30

Results in:

/**/
jQuery1113038504008506424725_1437475882811({
    "continue": {
        "iistart": "2015-06-23T05:30:36Z",
        "continue": "||"
    },
    "query": {
        "pages": {
            "6672": {
                "pageid": 6672,
                "ns": 6,
                "title": "Datei:Server\u00dcbersicht.png",
                "index": 1,
                "imagerepository": "local",
                "imageinfo": [{
                    "timestamp": "2015-06-23T05:31:57Z",
                    "size": 188839,
                    "width": 3000,
                    "height": 1606,
                   ....
                    "mediatype": "BITMAP"
                }]
            }
        }
    }
})

When using the astericks, the VE request works, but is repeated endlessly:

I could not reproduce the error on officewiki (a private wiki which is about a week behind master). Both your examples return a readapidenied error (which is a bug on its own right, reported as T106425). The VE media selector works fine, with or without an asterisk.

You could try to reproduce the bug in a controlled environment by using MediaWiki-Vagrant with the private and visualeditor roles.

See also T63151 and https://www.mediawiki.org/wiki/Topic:Rb7adzuz9pt6ifno