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

Question

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

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

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

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

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

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

Answer 1

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

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

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

• Убедитесь, что провайдер Session возвращает null из newSessionInfo вызова. По умолчанию реализация ImmutableSessionProviderWithCookie уже вернет null из этого вызова, потому что canChangeUser возвращает false. Если ваша реализация изменяет эту логику, так что в некоторых случаях newSessionInfo возвращает ненулевое значение, вам придется переопределить его.

• В методе Вашей сессии провайдера provideSessionInfo(WebRequest $request) добавить:

  // For API requests, ignore 
  if (defined('MW_API')) { 
      return null; 
  } 
  

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