Hi this may be related to T140961 and T140587

Since to use CACHE_ACCEL you need to have one of the caches there like apcu and xcache.

But this should now be fixed in the tasks I linked pending the patch that was cherry picked to REL1_27 being merged.

@Ciencia_Al_Poder would you be able to get the users to try https://gerrit.wikimedia.org/r/#/c/313756/ please?

And if you could reproduce the problem could you also try https://gerrit.wikimedia.org/r/#/c/313756/ please?

That would also explain my problem too using php 5.5+

https://github.com/wikimedia/mediawiki/blob/d175b391ae2a77e3183b2608bb4422782af092a1/includes/Setup.php#L701

This was T49162: Installer should not default to CACHE_NONE if CACHE_ACCEL is supported / rMWb3dc2fedc5e3: installer: Choose CACHE_ACCEL as the default if available.

This is causing problems when the cache is not persistent across requests, and MediaWiki will complain about "session hijacking".

Why is CACHE_ACCEL not persistent across requests? That kind of defeats the whole point of APCu...

@Legoktm apcu support was added yesterday so maybe this is fixed in the support?

In T147161#2683519, @Paladox wrote:

@Legoktm apcu support was added yesterday so maybe this is fixed in the support?

No, that's entirely unrelated.

@Legoktm but you said

"Why is CACHE_ACCEL not persistent across requests? That kind of defeats the whole point of APCu..."

But if CACHE_ACCEL wasn't using apcu then it would not work as intended.

In T147161#2683590, @Paladox wrote:

@Legoktm but you said

"Why is CACHE_ACCEL not persistent across requests? That kind of defeats the whole point of APCu..."

But if CACHE_ACCEL wasn't using apcu then it would not work as intended.

Paladox, I don't think you understand what the issue here is. If APC(u) wasn't detected, then the installer wouldn't have picked it. APC and APCu are interchangable names in this case.

Maybe we will want to set $wgSessionCacheType to CACHE_DB if we set CACHE_ACCEL?

Oh yep I see now, sorry.

But the apcu support will help users who did pick CACHE_ACCEL manually, to fix the session to. Thanks for explaining

I don't know if they are using APCu or any other opcache detected by MediaWiki.

Also, the problem may happen if the webserver is using multiple threads to handle requests, and different requests (from the same user) reach different threads randomly, so the "persistence" is scoped to a single thread and each request gets completely different cached data.

That's an extract from an IRC conversation from yesterday:

FWIW, APCu isn't an opcode cache. In recent versions of PHP, the opcode cache was pulled out of APC into Zend Opcache, leaving the "userland" caching of APC for storing of other stuff

And I've no idea if the APCu fixes going in help/hinder/do nothing to help this

In T147161#2683333, @Legoktm wrote:

Why is CACHE_ACCEL not persistent across requests?

This is probably the critical question here. The answer may have something to do with the larger infrastructure, e.g. if there's some common webserver+PHP that is hitting a case like this.

Doing this

$wgMainCacheType = CACHE_ACCEL;
$wgSessionCacheType = CACHE_DB;

is still causing the same problem with mw 1.28 wmf 20.

Note: That I also had it set to CACHE_ANYTHING before and that was still causing problems too.

In T147161#2685170, @Paladox wrote:

Doing this

$wgMainCacheType = CACHE_ACCEL;
$wgSessionCacheType = CACHE_DB;

is still causing the same problem with mw 1.28 wmf 20.

If you're seeing a problem when $wgSessionCacheType = CACHE_DB;, that's a different problem than the problem that is being described here.

Change 313844 had a related patch set uploaded (by Paladox):
Set $wgSessionCacheType to CACHE_DB if CACHE_ACCEL is set

https://gerrit.wikimedia.org/r/313844

@Anomie hi, clearing my cache fixes the problem, but then I carn't keep clearing my cache everytime I want to login into my own wiki, T138168

Since it works in MW 1.26 but broke in 1.27, so between those two releases something broke cache and caused the new session based login system to not work as intended, but it works as intended for Wikimedia since they use varnish and memcache.

Reason I doint want to keep clearing my cache is because I doint want to keep signing into my websites and other websites.

Yeah, we had problems for a while with CACHE_ACCEL not being persistent (e.g. T138072: Persistent login session issue on some wikis (due to XCache not saving data across requests?)). Maybe the installer could just test for that?

In-memory caching is generally superior for sessions compared to a DB, so if we can reliably detect whether CACHE_ACCEL is persistent or not, maybe we could define something like CACHE_PERSISTENT which has a fallback chain of memcached -> accel (if persistent) -> DB?

Note that pre-1.27 sessions were stored in files (or whatever was configured in php.ini) unless $wgSessionsInObjectCache was set, so this issue will hit some sites that upgrade to 1.27 as well, not just fresh installs. If we could come up with some more clever default (non-installer) behavior that can be backported to 1.27, that would be great.

@Paladox: If you have $wgSessionCacheType = CACHE_DB; already, it's not the same issue. On this task I don't care what you can do to work around your issue or how inconvenient that is for you because this task is not about your issue. Go discuss your issue on T138168; I'd recommend starting with providing the information requested in T138168#2393690.

Hi yes sorry wrong task to disccuss my problem is.

Change 313844 abandoned by Paladox:
Set $wgSessionCacheType to CACHE_DB if CACHE_ACCEL is set

https://gerrit.wikimedia.org/r/313844

With the backports of rMW61f778256c and rMW14aa034af6 into REL1_27 and REL1_28 the underlying session problem shouldn't happen anymore. Still, may be worth investigating why installer suggests CACHE_ACCEL when it doesn't work

I am having the same problem. Everything was working fine on my Wiki until this morning when I tried to login i was getting the message below

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.

MediaWiki 1.30.0

I had it to

$wgMainCacheType = CACHE_NONE;

when i started to have the issue this morning i set it to

$wgMainCacheType = CACHE_ACCEL;

but still having the same issue

Thanks

I'd add that if CACHE_DB is used, sesions are stored in objectcache table which is unconditionally truncated every time you run update.php. This defeats the reliability of CACHE_DB for sites that frequently run update.php.