Scripto 1.0.0 Login Issue

[stop14]

I’m troubleshooting an problem with Scripto authentication on an Omeka 2 installation. The site is using MediaWiki version 1.35.2 .

For some reason MediaWiki authentication doesn’t persist after login from Scripto. The MediaWiki API is working and successfully authenticates users, but it seems to drop the session immediately. The most obvious symptom is the presentation of a login UI after a notification of successful authentication.

A little digging suggests that MediaWiki might be rejecting the session cookies passed to it in the ApiClient->queryUserInfo() method. I can see the cookies being added to the request but every response seems to be Anonymous.

Has anyone encountered this? Is there some obvious configuration I’m missing?

[jimsafley]

I can’t reproduce this using the same version of MediaWiki (1.35.2). I don’t see anything in Scripto’s code that would account for a failed authentication, but perhaps you could try upgrading MediaWiki to the most recent version (1.39.1)? Did you recently upgrade MediaWiki or make changes to its configuration?

A little digging suggests that MediaWiki might be rejecting the session cookies passed to it in the ApiClient->queryUserInfo() method. I can see the cookies being added to the request but every response seems to be Anonymous.

Scripto saves MediaWiki cookies in a session, so you shouldn’t see the cookies in a browser development tool. Where do you see the cookies being added?

[stop14]

First of all, thank you for time and responsiveness. It’s very much appreciated. I’ve upgraded my local instance to MediaWiki 1.39 and installed a fresh version of Scripto 1.0.0. Sadly this hasn’t resolved the issue.

Perhaps a little context here first. A client noticed some spam postings on an active Scripto/Mediawiki instance, which was mitigated by restricting access for Anonymous users via the $wgGroupPermissions['*']['edit'] = false; setting in MediaWiki. This revealed the login issue described; users can log in via the Scripto toolbar, receive a notice of login success, but then receive a permissions error from MediaWiki when trying to submit.

It seems like MediaWiki is successfully authenticating and setting user session cookies, but then not recognizing them when the API passes them back. When I said I could “see” them I just meant I could see in the code that the session cookies were being added to the httpClient handler in the ApiClient constructor, and retrieved from the httpClient after a login request. A var_dump of $this->httpClient->getCookies() method before an after the request suggests that the session cookie info is being set.

But every call to Scripto\Mediawiki\ApiClient->queryUserInfo() returns Anonymous.

I feel like there’s a configuration issue here but I can’t see it.

I’ll follow with the story in pictures.

[stop14]

Valid MediaWiki credentials are submitted via the Scripto toolbar:

[stop14]

Scripto displays a successful login message. However, when I dump the value of $this->userInfo after the request in Scripto\Mediawiki\ApiClient->queryUserInfo() I get anonymous user data instead of the expected “Agile Production” user.

If I try to save a change, MediaWiki throws a permissions error:

Scripto\Mediawiki\Exception\EditException: The action you have requested is limited to users in the group

At this stage I’m not sure where to look next.

[jimsafley]

Try temporarily removing the $wgGroupPermissions and see if that works. Beyond the change to $wgGroupPermissions, have any other settings been changed? Has the server environment changed? Nothing immediately comes to mind why you’re seeing such unusual behavior, but I’ll continue to think about it.

[stop14]

Thank you again for taking the time with this (and for writing a great tool!).

The login issue isn’t resolved when $wgGroupPermissions is set back to default, but it does allow posting again (albeit anonymously).

My next step is to see if I can at least demonstrate the expected authenticated behaviour in the most recent Omeka 4 version. This could be a moot point if I can convince the client to upgrade to the latest.

Do let me know if a light bulb goes on, however.

Cheers!

[jflatnes]

You might, if you’re interested in still looking, dump the response from the clientlogin request. Scripto only checks for FAIL status to report if there was a login issue, but there are other less-common statuses, and it’s possible some other detail of your MediaWiki configuration (perhaps 2-factor authentication?) results in one of those that Scripto doesn’t handle.

[stop14]

Hi John. I appreciate you diving in (it’s Bill Kennedy at Agile btw … we met awhile back at a UVA conference).

It seems to be passing its login. Here’s the clientlogin response:

array(1) { ["clientlogin"]=> array(2) { ["status"]=> string(4) "PASS" ["username"]=> string(16) "Agile Production" } }

But here’s the userinfo response:

Array ( [batchcomplete] => 1 [query] => Array ( [userinfo] => Array ( [id] => 0 [name] => 127.0.0.1 [anon] => 1 [groups] => Array ( [0] => * ) [implicitgroups] => Array ( [0] => * ) [editcount] => 0 [realname] => [email] => ) ) ) bool(true)

[jflatnes]

Hi again, Bill.

Unfortunately I’m at a bit of a loss on this one. I assume logging in works fine on the MediaWiki site itself? The only things I’m left wondering about are if, for example, the API login is returning the wrong cookie or something like that.