Вход в Mediawiki отменен, чтобы предотвратить захват сеанса

Я только что создал страницу MediaWiki 1.29.0 на машине AS400 IBM i. Я использую MariaDB в качестве базы данных. Я использую PHP 5.5.37

Каждый раз, когда я пытаюсь войти в учетную запись, я получаю сообщение об ошибке:

Кажется, что проблема связана с вашим сеансом входа в систему; это действие было отменено в качестве меры предосторожности против захвата сессии. Вернитесь на предыдущую страницу, перезагрузите эту страницу и повторите попытку.

Очевидно, поведение, которое я ищу, - это войти в систему.

Я пробовал:

изменение $wgMainCacheType и $wgSessionCacheType на различные перестановки CACHE_NONE, CACHE_ACCEL, CACHE_DB и CACHE_ANYTHING.
создание каталога tmp и установка его разрешений.
восстановление моего файла LocalSettings.php.
session.referer_check=off в php.ini

Я проверил, и я знаю, что мои файлы cookie включены (я могу вызвать document.cookie; и вернуть данные).

Этот вопрос задан до здесь и связанные вопросы внутри, но никакие решения не устранили мою проблему. Они также имеют дело с более старой версией WikiMedia, хотя я не знаю, имеет ли это значение в этом случае.

EDIT: Я также получаю такое же поведение, когда пытаюсь создать новую учетную запись. Тем не менее, я могу перемещаться по вики, создавать страницы и редактировать страницы без какой-либо ошибки.

Вот мой заголовок запроса:

Cache-Control: private, must-revalidate, max-age=0
Connection: close
Content-language: en
Content-Type: text/html; charset=UTF-8
Date: Thu, 10 Aug 2017 13:48:36 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Link: </<path>/resources/assets/logo.png?88d75>;rel=preload;as=image
Server: Apache
Set-Cookie: ZDEDebuggerPresent=php,phtml,php3; path=/
Set-Cookie: <wikiname>_session=n7gs0ct99ck5i2juq0togto9q7bfou6u; path=/; secure; httponly
Transfer-Encoding: chunked
Vary: Accept-Encoding,Cookie
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Powered-By: PHP/5.5.37 ZendServer/8.5.5
X-UA-Compatible: IE=Edge

Вот мой заголовок ответа:

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:ZDEDebuggerPresent=php,phtml,php3
Host:tdidev:10080
Referer:http://<wikiepath>/index.php?title=Special:UserLogin&retirnto=Main+Page
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Ответ 1

Наконец-то я нашел проблему для своей проблемы. По умолчанию MediaWiki передает cookie <wikiname>_session с установленным безопасным флагом. Взято из OWASP:

Безопасный флаг - это параметр, который может быть задан сервером приложений при отправке нового файла cookie пользователю в ответ HTTP. Цель безопасного флага заключается в том, чтобы предотвратить обнаружение файлов cookie неавторизованными сторонами из-за передачи файла cookie в виде открытого текста.

Для достижения этой цели браузеры, поддерживающие безопасный флаг, будут отправлять cookie только с защищенным флагом, когда запрос будет отправлен на страницу HTTPS. С другой стороны, браузер не отправит cookie с установленным безопасным флагом по незашифрованному HTTP-запросу.

Итак, моя установка MediaWiki правильно создает и кэширует токен сеанса, и он все равно передает его через заголовок ответа. Однако, поскольку мой браузер видит http вместо https, что касается маркера. Строка Set-Cookie просто игнорируется.

В php.ini указан параметр session.cookie_secure, но MediaWiki игнорирует этот флаг.

Вместо этого решение должно было добавить эту строку в конец моего файла localSettings.php:

$wgCookieSecure = false;

Ответ 2

У меня было что-то подобное в другом приложении, когда sessionId обновлялся из последовательности.

Итак, вы обычно запрашиваете форму входа в систему, и она создает сеанс с sessionId и сохраняет это где-то.

Затем вы отправляете форму, она связывает ее с исходным идентификатором sessionId, проверяет вашу аутентификацию и либо регистрируется в исходном сеансе, либо создает новую, либо обновляет ваши данные (обычно с помощью команды HTTP Set-Cookie, которую вы можете см. в журнале сети).

Но вы можете следить за всем, просматривая sessionId в ваших текущих файлах cookie и любой токен в форме (чтобы предотвратить повторы), и проверяя его против файла /tmp/php -session-xxx (возможно, в /var/lib/php ) или любую другую базу данных, в которой он хранит сеанс.

Что подсказывало мне о моей проблеме, было то, что к тому моменту, когда я собирался отправить форму с определенным sessionid, этот sessionid больше недействителен. Следовательно, я не смог проверить повторные проверки, и у меня была ошибка, похожая на вашу. Оказалось, что в моем случае это было связано с репликацией баз данных, которая не соответствовала тому, как к ним обращались вниз по течению, поэтому я мог попытаться получить доступ к сеансу, который еще не был создан.

Глядя на весь ваш код, sessionIds не совпадают. wpTokenLogin начинается с 510a85, но ваш сеанс wiki в SetCookie начинается с n7gs0c, а в вашем журнале он говорит о 6ov933... Поэтому, предполагая, что вы скопировали/вставляли из разных попыток, вам нужно пройти через него из чистого состояния и убедитесь, что все выглядит так, как показано на одном сеансе. Если нет, попробуйте выяснить, что происходит с сеансом, который у вас есть (если он создан/изменен) или почему вы не получаете правильный, если он создан, но никогда не передавался вам должным образом.

Тем не менее, я просто посмотрел на клиентскую сторону, чтобы войти в нашу собственную версию mediawiki, а wpLoginToken, wikidb_session и JSESSIONID тоже не совпадают (хотя я ожидал бы одного из они появятся в журнале wiki, к которому у меня тоже нет доступа).

Если вам нужно, grep источник для сообщения об ошибке, который вы находите, и вставьте error_log(__FILE__.':'.__LINE__.' '.var_export(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS), true));, чтобы найти работу по резервному копированию стека, чтобы увидеть, что не соответствует, для генерации ошибки.