Hello,
I successfully upgraded/migrated my old wiki 1.26.0 to a new wiki 1.37.2 about a month ago. But now I realized I couldn't log in the wiki to edit content. I was not sure what my old user password was but assuming the old password was less than 8 chars. So I used changePassword.php to reset my password and set a new one longer than 8 chars.
But when I used it to log in my wiki, it seems to accept but goes back to original page with only "Log in" link on the top right corner, which means I'm not logged in. I immediately checked LocalSettings.php if $wgReadOnly was still configured after the upgrade, which was commented out with the leading '#'.
What could cause this behavior of the wiki?
Thanks,
Toshi
Hi,
On Wed, 2022-05-11 at 22:15 -0700, Toshi Esumi wrote:
I successfully upgraded/migrated my old wiki 1.26.0 to a new wiki 1.37.2 about a month ago. But now I realized I couldn't log in the wiki to edit content. I was not sure what my old user password was but assuming the old password was less than 8 chars. So I used changePassword.php to reset my password and set a new one longer than 8 chars.
But when I used it to log in my wiki, it seems to accept but goes back to original page with only "Log in" link on the top right corner, which means I'm not logged in. I immediately checked LocalSettings.php if $wgReadOnly was still configured after the upgrade, which was commented out with the leading '#'.
What could cause this behavior of the wiki?
See also https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems
Cheers, andre
On 5/11/22 22:34, Andre Klapper wrote:
Hi,
See also https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems
Cheers, andre
Thanks Andre. I should have searched doc with keywords "mediawiki" "login problems". This doc was Google's top match.
I appreciate the info.
Toshi
On Thu, May 12, 2022 at 1:16 AM Toshi Esumi email2@toshiesumi.com wrote:
I successfully upgraded/migrated my old wiki 1.26.0 to a new wiki 1.37.2 about a month ago. But now I realized I couldn't log in the wiki to edit content. I was not sure what my old user password was but assuming the old password was less than 8 chars. So I used changePassword.php to reset my password and set a new one longer than 8 chars.
But when I used it to log in my wiki, it seems to accept but goes back to original page with only "Log in" link on the top right corner, which means I'm not logged in. I immediately checked LocalSettings.php if $wgReadOnly was still configured after the upgrade, which was commented out with the leading '#'.
What could cause this behavior of the wiki?
I ran into this issue (or a very similar issue) several years ago. Or I had the same symptoms. Verify $wgServer matches the server name in httpd.conf .
MediaWiki 1.34 changed the default value to '$wgServer = false;' I think that's what broke logins for us. Also see https://www.mediawiki.org/wiki/Manual:$wgServer .
Here are my notes in LocalSettings.php and httpd.conf:
$ cat LocalSettings.php ... # Protocol-relative URLs. The server will serve over HTTP or # HTTPS, depending on what the user requested. $wgServer must # match the server name in httpd.conf or login will break $wgServer = '//www.cryptopp.com'; $wgCanonicalServer = 'https://www.cryptopp.com'; $wgSitename = 'Crypto++ Wiki';
# Security related administrivia $wgSecureLogin = true; $wgCookieHttpOnly = true; $wgCookieSecure = 'detect';
And:
# cat /etc/apache2/sites-enabled/cryptopp.conf <VirtualHost *:80> ... ServerName cryptopp.com ServerAlias www.cryptopp.com *.cryptopp.com
# https://linuxize.com/post/redirect-http-to-https-in-apache/ Redirect permanent / https://cryptopp.com/ ...
Jeff
On 5/12/22 04:31, Jeffrey Walton wrote:
I ran into this issue (or a very similar issue) several years ago. Or I had the same symptoms. Verify $wgServer matches the server name in httpd.conf .
MediaWiki 1.34 changed the default value to '$wgServer = false;' I think that's what broke logins for us. Also see https://www.mediawiki.org/wiki/Manual:$wgServer .
Here are my notes in LocalSettings.php and httpd.conf:
$ cat LocalSettings.php ... # Protocol-relative URLs. The server will serve over HTTP or # HTTPS, depending on what the user requested. $wgServer must # match the server name in httpd.conf or login will break $wgServer = '//www.cryptopp.com'; $wgCanonicalServer = 'https://www.cryptopp.com'; $wgSitename = 'Crypto++ Wiki';
# Security related administrivia $wgSecureLogin = true; $wgCookieHttpOnly = true; $wgCookieSecure = 'detect';
And:
# cat /etc/apache2/sites-enabled/cryptopp.conf <VirtualHost *:80> ... ServerName cryptopp.com ServerAlias www.cryptopp.com *.cryptopp.com
# https://linuxize.com/post/redirect-http-to-https-in-apache/ Redirect permanent / https://cryptopp.com/ ...Jeff
Thanks Jeff. It was spot on.
First I didn't know they needed to match and I changed $wgServer side only. Also I recently installed a certificate to add SSL support then forgot to update to $wgServer = https://...
Now I can log in with my username. I appreciate your help.
Toshi
On Fri, May 13, 2022 at 1:14 AM Toshi Esumi email2@toshiesumi.com wrote:
On 5/12/22 04:31, Jeffrey Walton wrote:
I ran into this issue (or a very similar issue) several years ago. Or I had the same symptoms. Verify $wgServer matches the server name in httpd.conf . ...
Thanks Jeff. It was spot on.
First I didn't know they needed to match and I changed $wgServer side only. Also I recently installed a certificate to add SSL support then forgot to update to $wgServer = https://...
Glad to hear it. It took us a couple of days to work out the problem when we experienced it.
I _think_ what happened was, the server was serving pages that violated the browser's Same Origin Policy (SOP). So you would login over https using host example.com, and then you would get a http page from www.example.com and that would blow away the cookie.
In the browser's security model, an origin is a {protocol, host, port} triplet. All requests have to use the same origin. Switching between http and https, and switching between hosts example.com and www.example.com would muck things up.
That's why $wgServer, $wgCanonicalServer, ServerName and ServerAlias had to line-up properly.
Jeff
mediawiki-l@lists.wikimedia.org