Phpmyadmin Не удалось установить файл cookie сеанса. Возможно, вы используете HTTP вместо HTTPS

Ну, это одно из двух. Либо у вас не включен TLS / HTTPS в вашем производственном блоке (что вам обязательно нужно! - хорошие ресурсы для начала работы - это Давайте зашифровать и любой хост, который вы используете), либо вы, вероятно, пытаетесь получить доступ к серверу разработки в производственном режиме. В последнем случае, хотя я сам не знаком с PHPMyAdmin, я бы предположил, что где-то есть файл конфигурации, который диктует, когда он должен действовать как производственный сервер, а не как локальный, и вы можете просто переключить его. Но определенно не переключайте свой рабочий сервер на работу как сервер разработки, тогда вы просто отказываетесь от безопасности ради удобства, которое в конечном итоге вернется, чтобы вас укусить.

Кажется, вы не первый, кто это испытает; перед вами еще один: https://github.com/phpmyadmin/phpmyadmin/issues/14184

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

Таким образом, в настоящее время это открытая и известная ошибка, и, надеюсь, она будет исправлена ​​в следующем выпуске phpMyAdmin.

У меня была эта проблема в прошлом, но мне удалось ее решить, используя инструкции, приведенные в этом ответе. (с использованием phpMyAdmin версии 4.8.0.1)

Перейдите к

config.inc.php

в файлах вашего сервера и изучите следующий раздел:

/* Authentication type and info */
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['user'] = 'username';
$cfg['Servers'][$i]['password'] = 'password';
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['AllowNoPassword'] = true;

Если это еще не выполнено, закомментируйте строки пользователя и пароля и проверяет, что auth_type установлен на печенье.

По моему опыту, это действие необходимо выполнить, чтобы phpMyAdmin работал с аутентификацией файлов cookie, прежде чем вы продолжите.

Затем выполните следующие действия, чтобы решить, что cookie сеанса не работает с HTTP:

1. Введите настройки своего браузера (например, для Google Chrome перейдите в chrome: // settings /)
2. Попытайтесь найти настройку для очистки файлов cookie, кешированных данных, изображений и файлов, истории и т. д.
3. После того, как вы его успешно найдете, очистите историю просмотров вашего браузера, историю загрузок, кешированные изображения и файлы, а также настройки содержимого.
4. Удалите файлы cookie для страницы входа phpMyAdmin. Примечание:В Internet Explorer несколько затруднительно просматривать и удалять файлы cookie. Если вам нужна помощь, доступна интернет-статья от Спроси Лео о просмотре файлов cookie в IE.

Мне пришла в голову идея выполнить приведенные выше инструкции, потому что я заметил, что кто-то в эта проблема GitHub упоминает частный режим. Это комментарий от nik6018:

As stated in #14234 Login via HTTP works if in private mode, but doesn't work in normal session. I tried to clear the cookie for the domain but still the same issue.

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

Просто очистите файлы cookie и кеш в своем браузере. Вот как это сработало для меня.

У меня была та же проблема, но в моем случае проблема была в моем VPN, поэтому я отключил его.

Если вы используете VPN, вам необходимо отключить его. или просто отключите блокировку файлов cookie.

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

Я только что столкнулся с этой проблемой, используя Firefox 61 на сайте, который я регулярно посещал, поэтому я знал, что мои настройки конфигурации верны. Фактически, я мог использовать приватный режим. Итак, в частном режиме, используя инструменты разработчика Firefox, я очистил ВСЕ файлы cookie сеанса и VOILA. Сработало отлично.

Мое решение заключалось в том, чтобы отключить (добавить исключение для моего домена) расширение Firefox «Privacy Badger».

Как только я это сделал, я смог войти в систему.

Другие решения в этом посте (config.ini.php, кеш браузера, VPN) ничего не сделали для меня. Похоже, проблема в первую очередь связана с конфигурацией среды / браузера, которая может быть уникальной для каждого человека.

Я не думаю, что это проблема PHPMyAdmin.

У меня была эта проблема сегодня, и вот шаги, которые я сделал, которые помогли мне исправить ее в Chrome:

1- Щелкните правой кнопкой мыши в любом месте страницы и выберите «Проверить» или нажмите F12, чтобы открыть инструменты разработчика.

2- В верхнем меню выберите «Приложение».

3- Щелкните Cookies в левом меню.

4- Вы найдете там несколько файлов cookie, щелкните каждое из них и нажмите «X» вверху, чтобы удалить их. Удалив их все, обновите страницу.

Только сегодня была эта проблема в Chrome, у меня сработало следующее, поэтому я подумал, что поделюсь ею.

Перейдите в Инспектор> Приложение> Очистить хранилище> Идите и очистите все.

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

В моем случае расширение chrome, вызвавшее проблему, называлось: Безопасный сканер торрентов.

Проблема должна быть решена с помощью phpMyAdmin 4.9.2, поскольку я исправил ее, но если у вас все еще есть проблема, прокомментируйте https://github.com/phpmyadmin/phpmyadmin/issues/15634

Уильям, команда phpMyAdmin

Я нашел одну причину этой ошибки

Ссылка: https://github.com/phpmyadmin/phpmyadmin/issues/15634#issuecomment-571713024

Если в вашем браузере есть безопасный файл cookie, и вы просматриваете незащищенное соединение, незащищенное соединение отправит новый небезопасный файл cookie. И браузер откажется перезаписывать Secure. Это приводит к бесконечной петле.

«Не удалось установить файл cookie сеанса. Возможно, вы используете HTTP вместо HTTPS для доступа к phpMyAdmin».

Я также попробовал "Privacy Badger", но не смог воспроизвести проблему.

Я столкнулся с этой проблемой на phpMyAdmin-4.9.1. Я просто переименовал файл конфигурации с config.sample.inc.php в config.inc.php.

У меня возникла эта проблема, потому что я размещаю phpmyadmin за обратным прокси-сервером nginx, используя Docker Compose. В моем файле docker-compose.yml у меня было:

db-admin:
    # https://hub.docker.com/r/phpmyadmin/phpmyadmin/
    image: phpmyadmin/phpmyadmin:latest
    restart: always
    environment:
      - PMA_ARBITRARY=1
      - PMA_HOST=http://db
      - PMA_PORT=3306
      - PMA_ABSOLUTE_URI=http://localhost/db-admin/  # necessary because the db-admin is hosted behind a reverse proxy.
    ports:
      - 8084:80
    depends_on:
      - db
    networks:
      - shared-network

Из-за обратного прокси и PMA_ABSOLUTE_URI я могу использовать это приложение только на http://localhost/db-admin, но не на http://localhost:8084.

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

Часть сообщения, в которой говорится, что Maybe you are using HTTP instead of HTTPS. - это «отвлекающий маневр», потому что переход на HTTPS не решает проблему в данном конкретном случае.

Для этого конкретного случая, в docker-compose.yml переменная среды PMA_HOST должна быть установлена ​​соответствующим образом, например:

services:
    phpmyadmin:
        environment:
          - PMA_HOST=mysql

Более полный пример, который правильно работает в Laravel Sail (который является конкретной реализацией стека контейнеров Docker), но только после внесения этого изменения, выглядит следующим образом:

services:
    phpmyadmin:
        image: phpmyadmin
        restart: always
        ports:
          - 8080:80
        environment:
          - PMA_HOST=mysql
        networks:
          - sail

Теперь phpMyAdmin можно успешно получить по адресу http: // localhost: 8080 (обратите внимание на отсутствие HTTPS), и ошибка больше не возникает.