Пользователи бота MediaWiki читают права?

Question

Пользователи бота MediaWiki читают права?

В обновлениях MediaWiki 1.27 были сделаны некоторые изменения аутентификации для API (в дополнение к изменениям аутентификации в целом для движка Wiki). Как часть этого, я, кажется, сталкиваюсь с ошибкой прав доступа в вики, которая запрещает чтение анонимным пользователям.

В вики есть $wgGroupPermissions['*']['read'] = false; отключить доступ для анонимных пользователей.

Но с помощью бота, созданного новым Special:BotPasswords страница, кажется, имеет проблему. Я создал бота для существующего admin Пользователь, который предоставляет «Базовые права» доступ к новому боту в качестве базового уровня (и «Базовые права» включает read а также writeapi).

Используя API, я могу успешно получить токен входа и войти (который возвращает cookie для установки сеанса), но затем использовать этот cookie сеанса, чтобы попытаться выполнить запрос страницы (например, листинг). allpages) приводит к readapidenied ошибка («Вам нужно разрешение на чтение, чтобы использовать этот модуль»).

Является readapi новое разрешение я должен дать где-нибудь? Или недостаточно просто представить файл cookie сеанса, чтобы связать запрос списка страниц с запросом на вход в систему (как я могу передать авторизацию из login переадресация на другие звонки?)? Или это просто ошибка в новой пользовательской инфраструктуре ботов?

Я предполагаю, что моя ошибка в переносе информации о сеансе в запрос списка, так как если я временно $wgGroupPermissions['*']['read'] вернуться к trueи использовать assert=user вариант запроса, он возвращается с assertuserfailed ошибка, указывающая, что пользователь не авторизован.

2

bots mediawiki mediawiki-api php

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

В этой ситуации оказалось, что это не связано с BotPassword инфраструктура, а точнее отдельное расширение:

У меня также был на этой вики пользовательский поставщик сессий ( ImmutableSessionProviderWithCookie), который не был должным образом убираться с пути BotPassword поставщик сессий.

Итак, если у вас есть Session Provider, который не должен быть активным для запросов API:

Убедитесь, что поставщик сеанса возвращается null из newSessionInfo вызов. По умолчанию ImmutableSessionProviderWithCookie реализация уже вернется null из этого звонка, потому что canChangeUser возвращается false, Если ваша реализация изменяет эту логику так, что в некоторых случаях newSessionInfo возвращает ненулевое значение, вам придется переопределить его.
В вашем провайдере сеансов provideSessionInfo( WebRequest $request ) метод, добавьте:
```
// For API requests, ignore
if ( defined( 'MW_API' )) {
return null;
}
```

Пока newSessionInfo метод и provideSessionInfo метод оба возврата nullдля этого поставщика сеансов файл cookie сеанса не будет создан, поэтому он не будет мешать другим поставщикам файлов cookie сеанса (например, BotPassword).

1