2016-12-01 90 views
2

随着MediaWiki 1.27的更新,API进行了一些身份验证更改(与Wiki引擎的身份验证更改一起进行)。作为其中的一部分,我似乎遇到了一个设置为不允许匿名用户阅读的wiki中的权限错误。MediaWiki bot用户阅读权限?

该wiki有$wgGroupPermissions['*']['read'] = false;关闭匿名用户的访问权限。

但是使用由新的Special:BotPasswords页创建的机器人似乎有问题。我为现有的admin用户创建了一个机器人,该用户授予对新机器人“基本权利”访问权限作为基准(以及“基本权利”包括readwriteapi)。

使用API​​,我可以成功获取登录令牌并登录(它会返回一个cookie来设置会话),但是随后使用该会话cookie尝试执行页面查询(如列出allpages)结果一个readapidenied错误(“您需要使用此模块的读取权限”)。

readapi我必须授予某处的新权限?或者,只是提供会话cookie不足以将页面列表请求链接到登录请求(我如何将login呼叫转移到其他呼叫?)?或者这仅仅是新的Bot用户基础架构中的一个错误?

我猜我的错误是在携带上的会话信息列表查询,因为如果我暂时把$wgGroupPermissions['*']['read']回到true,并使用assert=user查询选项,它回来与assertuserfailed错误,指示用户在未登录

回答

1

在这种情况下,它竟然没有被涉及到BotPassword基础设施,而是一个独立的扩展:

我也对这个wiki自定义会话提供商(一ImmutableSessionProviderWithCookie)这没有正确地摆脱的方式会话提供者。

所以,如果你有这不是应该的API请求激活一个会话提供:

  • 确保会话提供从newSessionInfo调用返回null。默认情况下,ImmutableSessionProviderWithCookie实现将从此调用返回null,因为canChangeUser返回false。如果您的实现更改了该逻辑,以致在某些情况下newSessionInfo返回非空值,则必须覆盖它。
  • 在您的会话提供的provideSessionInfo(WebRequest $request)方法,添加:

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

只要newSessionInfo方法和provideSessionInfo方法都返回null,没有会话cookie将被用于该会话提供创建的,所以它不会干扰其他会话cookie提供者(如BotPassword)。

+0

'ImmutableSessionProviderWithCookie :: newSessionInfo'总是返回null,并且通常对于不可变的提供者不这样做会很奇怪,因为整个不可变性的要点是提供者不控制任何用于身份验证的凭证会议。 – Tgr

+0

诚然,'ImmutableSessionProviderWithCookie'默认使用'SessionProvider :: newSessionInfo'逻辑,因为'ImmutableSessionProviderWithCookie :: canChangeUser'是'FALSE'其返回null。但在我的情况下,自定义会话提供被设计为备用会话管理工作,所以需要有'canChangeUser'设置为TRUE;为了让用户注销(并重新登录使用不同的手段)。我会改变我的答案的措辞,以减少特定于我的具体情况。 – MidnightLightning

+0

这听起来像一个可变的会话提供者(我猜文档对于不可变性的概念不是很清楚)。如果没有其他原因,从做API的请求吧吧(因为网络接口本身要求的东西,如手表/停止监视的API,我无法想象,运作良好),你可以确保该它返回的SessionInfo总是比BotPasswordSessionProvider返回的优先级低。 – Tgr