Scripto user rights errors

adehner · July 23, 2024, 1:26am

I’m trying to log in to a Scripto account and to transcribe an item in Omeka Classic 3.1.2, with Scripto 2.5, php 8.2, Center Row 1.8.0, and no other active plugins.

I’m noticing two problems that are interfering with transcription.

When I log in with my Scripto user credentials and open an item page for transcription, I do not see an “Edit” link. Instead I see the following message in the browser:

You don’t have permission to transcribe this page.

And the following two errors in the error log:

PHP Warning:  current() expects parameter 1 to be array, null given in /plugins/Scripto/libraries/Scripto/Document.php on line 800

PHP Warning:  in_array() expects parameter 2 to be array, null given in /plugins/Scripto/libraries/Scripto/Document.php on line 683

In MediaWiki’s LocalSettings.php, these permissions are set:

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = true;
$wgGroupPermissions['*']['createpage'] = false;
$wgGroupPermissions['user']['createpage'] = true;

I’m not sure whether Scripto login is working. When I log in, I see the message “Login successful” but the “Log in to Scripto” link persists instead of displaying my username. It seems like Scripto (and/or Mediawiki) isn’t recognizing my user info.

EDIT to add similar posts, though I’m not seeing resolution for these:

I see some things to try in this post which seems similar to my problem, so I’ll see what comes of that.
Another one, which seems similar as well.
And this one.
I saw another post where @jimsafley asked the poster to check user rights in the api with this request <MediaWiki URL>/api.php?action=query&meta=userinfo&uiprop=rights I did this and do see that “edit” is listed as one of my user rights.

jimsafley · July 23, 2024, 3:17pm

Your login isn’t working. This tends to happen when the “MediaWiki cookie prefix” is incorrect. Did you enter a cookie prefix when configuring the Scripto plugin?

adehner · July 23, 2024, 5:37pm

Thanks for the quick reply!
I entered the $wgDBprefix value from MediaWiki’s LocalSettings.php

adehner · July 23, 2024, 5:55pm

It doesn’t seem to be recognizing the cookie prefix though. I can change that prefix to random text and I get the same errors.

EDIT: I set $wgCookieprefix to the value in $wgDBprefix and this fixed the login issue. However I still can’t edit a transcription. These are the errors I see now:

Warning: Trying to access array offset on value of type null in /plugins/Scripto/libraries/Scripto/Document.php on line 683

Fatal error: Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in /plugins/Scripto/libraries/Scripto/Document.php:683 Stack trace: #0 /plugins/Scripto/libraries/Scripto/Document.php(683): in_array(‘edit’, NULL) #1 /plugins/Scripto/libraries/Scripto/Document.php(415): Scripto_Document->_canEdit(Array) #2 /plugins/Scripto/views/shared/index/transcribe.php(368): Scripto_Document->canEditTranscriptionPage() #3 /application/libraries/Omeka/View.php(114): include(‘/home//…’) #4 /application/libraries/Zend/View/Abstract.php(889): Omeka_View->_run(‘/home//…’) #5 /application/libraries/Zend/Controller/Action/Helper/ViewRenderer.php(912): Zend_View_Abstract->render(NULL) #6 /application/libraries/Zend/Controller/Action/Helper/ViewRenderer.php(933): Zend_Controller_Action_Helper_ViewRenderer->renderScript(‘index/transcrib…’, NULL) #7 /application/libraries/Zend/Controller/Action/Helper/ViewRenderer.php(972): Zend_Controller_Action_Helper_ViewRenderer->render() #8 /application/libraries/Zend/Controller/Action/HelperBroker.php(277): Zend_Controller_Action_Helper_ViewRenderer->postDispatch() #9 /application/libraries/Zend/Controller/Action.php(527): Zend_Controller_Action_HelperBroker->notifyPostDispatch() #10 /application/libraries/Zend/Controller/Dispatcher/Standard.php(308): Zend_Controller_Action->dispatch(‘transcribeActio…’) #11 /application/libraries/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http)) #12 /application/libraries/Zend/Application/Bootstrap/Bootstrap.php(106): Zend_Controller_Front->dispatch() #13 /application/libraries/Zend/Application.php(384): Zend_Application_Bootstrap_Bootstrap->run() #14 /application/libraries/Omeka/Application.php(73): Zend_Application->run() #15 /index.php(23): Omeka_Application->run() #16 {main} thrown in /plugins/Scripto/libraries/Scripto/Document.php on line 683

I’m also getting several deprecation errors for Scripto, in both the dashboard and public view. Would you like me to put these in a github issue, create a new thread in the forum, or add them to this thread?

jimsafley · July 23, 2024, 6:34pm

What version of MediaWiki are you running?

adehner · July 23, 2024, 6:38pm

1.42.1
Sorry for not including that earlier

jimsafley · July 23, 2024, 8:03pm

I can’t reproduce the errors using the same versions and permissions config. If I had to guess, it seems like Scripto is receiving unexpected data from your MediaWiki API.

Those warnings and the fatal error imply that Scripto_Service_MediaWiki::>getUserInfo('rights') returns null instead of the expected JSON array. The only way I figure that can happen is in Scripto_Service_MediaWiki::_request() when json_decode() attempts to decode the API response. It will return null if the JSON can’t be decoded. It’s not a MediaWiki error response, else you’d be getting a Scripto_Service_Exception. This is why I think Scripto is receiving unexpected data.

You mention that you can go to api.php?action=query&meta=userinfo&uiprop=rights using your browser. I wonder if your MediaWiki responds with something different when the request comes from Scripto’s HTTP client. Troubleshooting this will be difficult since you’re reaching a fatal error and I cannot reproduce it.

jimsafley · July 23, 2024, 8:22pm

If you can, open the following file for editing:

Scripto/libraries/Scripto/Service/MediaWiki.php

In Scripto_Service_MediaWiki::_request() output the $body like so:

$body = self::getHttpClient()->request('POST')->getBody();
var_dump($body); // Add this line
self::getHttpClient()->resetParameters();

Now reload the transcription page in your browser. Immediately before the warnings (under the “previous page | next page”) you should see the output of the var_dump(). What is that output?

adehner · July 23, 2024, 8:42pm

Okay, this is what’s below “previous page | next page”:

string(318) "
Forbidden
You don't have permission to access this resource.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

"

And this new bit is at the top of the page:

string(1083) "{"batchcomplete":"","query":{"userinfo":{"id":1,"name":"Adehner","groups":["bureaucrat","interface-admin","sysop","*","user","autoconfirmed"],"rights":["userrights","noratelimit","renameuser","editinterface","editsitecss","editsitejson","editsitejs","editusercss","edituserjson","edituserjs","block","createaccount","delete","bigdelete","deletedhistory","deletedtext","undelete","import","importupload","move","move-subpages","move-rootuserpages","move-categorypages","patrol","autopatrol","protect","editprotected","rollback","upload","reupload","reupload-shared","unwatchedpages","autoconfirmed","editsemiprotected","ipblock-exempt","blockemail","markbotedits","apihighlimits","browsearchive","movefile","unblockself","suppressredirect","mergehistory","managechangetags","deletechangetags","read","createtalk","writeapi","viewmyprivateinfo","editmyprivateinfo","editmyoptions","edit","createpage","minoredit","editmyusercss","editmyuserjson","editmyuserjs","editmyuserjsredirect","sendemail","applychangetags","changetags","editcontentmodel","viewmywatchlist","editmywatchlist"]}}}"
Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in /plugins/Scripto/libraries/Scripto/Document.php on line 141
string(467) "{"batchcomplete":"","query":{"pages":{"-1":{"ns":0,"title":".MQ.MQ","missing":"","contentmodel":"wikitext","pagelanguage":"en","pagelanguagehtmlcode":"en","pagelanguagedir":"ltr","protection":[],"restrictiontypes":["create"],"fullurl":"/index.php?title=.MQ.MQ","editurl":"/index.php?title=.MQ.MQ&action=edit","canonicalurl":"/index.php?title=.MQ.MQ"}}}}" string(487) "{"batchcomplete":"","query":{"pages":{"-1":{"ns":1,"title":"Talk:.MQ.MQ","missing":"","contentmodel":"wikitext","pagelanguage":"en","pagelanguagehtmlcode":"en","pagelanguagedir":"ltr","protection":[],"restrictiontypes":["create"],"fullurl":"/index.php?title=Talk:.MQ.MQ","editurl":"/index.php?title=Talk:.MQ.MQ&action=edit","canonicalurl":"/index.php?title=Talk:.MQ.MQ"}}}}" string(1266) "{"warnings":{"parse":{"*":"No \"title\" or \"contentmodel\" was given, assuming wikitext."}},"parse":{"title":"API","pageid":0,"text":{"*":"

.MQ.MQ\n
\n\n\n
"},"langlinks":[],"categories":[],"links":[{"ns":0,"*":".MQ.MQ"}],"templates":[{"ns":0,"*":".MQ.MQ"}],"images":[],"externallinks":[],"sections":[],"parsewarnings":[],"displaytitle":"API","iwlinks":[],"properties":[{"name":"noeditsection","*":""}]}}"
Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /plugins/Scripto/libraries/Scripto.php on line 760
string(1296) "{"warnings":{"parse":{"*":"No \"title\" or \"contentmodel\" was given, assuming wikitext."}},"parse":{"title":"API","pageid":0,"text":{"*":"

Talk:.MQ.MQ\n
\n\n\n
"},"langlinks":[],"categories":[],"links":[{"ns":1,"*":"Talk:.MQ.MQ"}],"templates":[{"ns":1,"*":"Talk:.MQ.MQ"}],"images":[],"externallinks":[],"sections":[],"parsewarnings":[],"displaytitle":"API","iwlinks":[],"properties":[{"name":"noeditsection","*":""}]}}"
Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /plugins/Scripto/libraries/Scripto.php on line 760

jimsafley · July 23, 2024, 9:10pm

It appears that your server is not authorizing that particular request to your MediaWiki API. This is odd since it’s authorizing every other request, given the other API responses you’re seeing.

Errors like this typically have something to do with how your web server is configured. Have you set up any redirects? For instance from http to https? Has your server environment changed since you initially configured Scripto or MediWiki?

adehner · July 23, 2024, 10:09pm

I checked .htaccess files for redirects as well as the server’s cpanel redirect tool. Not seeing anything in any of these places.

I installed Omeka and MediaWiki yesterday, and the errors appeared right away. Scripto pages are very slow to load as well. I increased the “keep alive” time, which helps somewhat. But I still get timeouts when Scripto pages load as well as database “has gone away” messages in the error log.

If I reach out to my server admins, is there something I should ask specifically?

jimsafley · July 23, 2024, 11:32pm

Generally, you could ask why the server would respond with that specific error. I doubt it’s related to file permissions. It could be related to DNS or redirects. If not those things, the only thing that makes some sense is a strict rate limiter that allows a limited number of requests within a short amount of time.

adehner · July 24, 2024, 12:23am

Thanks for your help today. I know you have other things to do, so I appreciate your attention to this.

I submitted a ticket with Reclaim. Hopefully I explained the problem clearly enough for them to investigate.

adehner · July 24, 2024, 7:53pm

Hi again.

I switched to a different Reclaim account and tested out the same versions of php (8), Scripto (2.5), Omeka (3.1.2), and MediaWiki (1.39.3). One difference here is that Omeka and MediaWiki are installed in their own subdomains.

When I var_dump($body) in this account, I don’t get a 403 forbidden error. Instead I see this:

But below this response, I have the same fatal error.

jimsafley · July 24, 2024, 8:07pm

Double check that your “MediaWiki API URL” configuration is correct and points to the API, not the main page.

adehner · July 24, 2024, 8:38pm

Yes, it points to the api: https://mediawiki.anneliesedehner.com/api.php
I’d added the below to LocalSettings.php because I was getting an Internal Server Error

$wgUsePathInfo = true

Just removed that because now I’m wondering if the Internal Server Error contains useful info:

And this is below the previous | next links:

jflatnes · July 24, 2024, 9:36pm

Something is making your server redirect the request here to the main wiki page.

I’m a little stumped on this one to be honest… I can only really vaguely point to some sort of server or configuration oddity. Your internal server error, pathinfo stuff… I would guess that points to an issue with .htaccess or something like that not correctly being set for your MediaWiki install’s current location. Whether that’s your underlying problem or not, I’m not sure.

My best guess would be that this is something your server is doing (certainly the previous Forbidden, and maybe the odd “go to the front page” result here) after getting several requests in quick succession to the MediaWiki install. This would account for why some of the internal Scripto requests seem to work, but not others.

Try this out as a test: where Jim had you put the var_dump($body); before, instead of that, put sleep(1);

The page will load even slower than before, but if the error goes away with that added, it will tell us that the problem relates to the timing of requests.

adehner · July 25, 2024, 4:57pm

Holy cow! That worked!
But, yes, it’s very slow.

jflatnes · July 25, 2024, 6:56pm

OK. Well we won’t be able to have that kind of sleeping in the live code for obvious reasons of performance. But it serves the purpose of pointing to the likely issue area.

I guess I’d check with Reclaim about firewall, rate-limiting or similar rules they might have in place, maybe specifically ones for the MediaWiki API? Certainly they’re best positioned to know if some sort of relevant limitations are in place, what they are if so, and how to adjust or work around them.

adehner · July 25, 2024, 10:01pm

I reached out to Reclaim.

Thanks so much. I appreciate the time you and @jimsafley have taken to inch along with me on this.