When one user creates an account and then attempts to log in, they’re met with a successful log in notice, but they’re not actually logged in. We have 100+ users who have been able to successfully create accounts/log in, and I’m not able to reproduce the issue myself.
It’s always the same user with problems and persists across browsers, using the same email. (Although the email doesn’t have any special characters or anything)
When I check the database in phpmyadmin for the user with problems, the db doesn’t seem to be saving their email. Not sure if that’s related. I have LocalSettings.php for the mediawiki installation set to not require email confirmation.
We’re running Mediawiki 1.45.3, Omeka S 4.2.0, Scripto 1.5.0
I’m looking into this. The detail about the email not being saved in the database is a useful clue.
It would help to know more about your MediaWiki setup: specifically, do you have any extensions installed that add extra steps to the login process (two-factor authentication, CAPTCHA, etc.)?
No extensions, no captcha. This is a relatively fresh installation and I haven’t touched the mediawiki installation much. I made some changes to localsettings to get it working and I can post those if it seems relevant.
In case it’s helpful to know, there are a handful of other users in the db with no email (3 out of 100+) with no email, but at least one that I can confirm can login and edit with no problem. Our installation also seems to send out confirmation emails but not password reset emails, if that might be related.
As you point out, we’ve seen similar reports in the past and want to narrow down what’s happening for this specific user. Could you add these two lines to the login() method in src/Mediawiki/ApiClient.php in the Scripto module?
The first goes directly after the $clientlogin = $this->request([...]) call (around line 963):
Then have the affected user attempt to log in and check your Apache error log (typically /var/log/apache2/error.log) for lines beginning with Scripto clientlogin and Scripto cookies.
The first line tells us what MediaWiki returned when the user tried to log in. The second tells us whether the authentication cookies were captured. Together they should tell us where the login is breaking down.
[19-May-2026 00:52:46 UTC] Scripto clientlogin for "USERNAME": {"status":"UI","requests":[{"id":"MediaWiki\\Auth\\PasswordAuthenticationRequest","metadata":[],"required":"optional","provider":"Password-based authentication","account":"USERNAME","fields":{"password":{"type":"password","label":"New password:","help":"Password for authentication.","optional":false,"sensitive":true},"retype":{"type":"password","label":"Retype new password:","help":"Password again to confirm.","optional":false,"sensitive":true}}},{"id":"MediaWiki\\Auth\\ButtonAuthenticationRequest:skipReset","metadata":[],"required":"optional","provider":"MediaWiki\\Auth\\ButtonAuthenticationRequest","account":"MediaWiki\\Auth\\ButtonAuthenticationRequest:skipReset","fields":{"skipReset":{"type":"button","label":"Skip","help":"Skip resetting the password.","optional":false,"sensitive":false}}}],"message":"Your password is not valid: \n* Passwords must be at least 8 characters.\n* The password entered is in a list of very commonly used passwords. Please choose a more unique password.\n\n\nPlease choose a new password now, or click \"Skip\" to change it later.","messagecode":"resetpass-validity-soft"}
[19-May-2026 00:52:46 UTC] Scripto cookies for "USERNAME": {"miaminat_lz9x1_bpai__session\/":{"name":"miaminat_lz9x1_bpai__session","domain":null,"path":"\/","secure":true,"expired":false},"UseDC\/":{"name":"UseDC","domain":null,"path":"\/","secure":true,"expired":false}}
(For anyone that finds this in the future, I’m on Reclaim and my error log was in the same directory as my omeka installation as error_log
That’s it! When this user tries to log in, MediaWiki is flagging their password as too weak or too common and asking them to change it before completing the login. Scripto doesn’t handle that step correctly - instead of showing the error, it displays a false “Successfully logged in” message while the user remains unauthenticated.
The immediate fix for this user is to have them log in directly to MediaWiki (not through Scripto) where they’ll be prompted to change their password. Once they’ve done that, they should be able to log in through Scripto normally.
I’ll also be releasing a code fix so that Scripto properly surfaces the error message instead of showing a false success in cases like this.