Форум пользователей Impera CMS
Impera CMS - отличный движок для лёгкого создания интернет магазина.
Обладает невероятным количеством функций, необходимых в онлайн торговле.

Ошибка в движке: вход администраторов

Следить
Главная
21:18
14 мар
#
?
Сергей написал:

Обнаружил ошибки:

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

2. После обновления до Последней версии, в администраторской части добавляешь админа, а потом пытаешся войти под новым тебя не пускает в админку, с рабатывает только первоначальный логин и пароль.

Помогите решить проблему номер 2, так как очень нужно.

Игрался с правами доступа не помогает.

02:22
15 мар
#
?
Jigga написал:

В хроме пробовали? Он не чистит кэш и возвратиться даст под липой.

Из мануала php: И Netscape Navigator и Internet Explorer очищают кэш аутентификации текущего окна для заданного региона (realm) при получении от сервера статуса 401. Это может использоваться для реализации принудительного выхода пользователя и повторного отображения диалогового окна для ввода имени пользователя и пароля. Некоторые разработчики используют это для ограничения авторизации по времени или для предоставления кнопки "Выход". Это поведение не регламентируется стандартами HTTP Basic-аутентификации, следовательно, вы не должны зависеть от этого. Тестирование браузера Lynx показало, что Lynx не очищает кэш авторизации при получении от сервера статуса 401, и, нажав последовательно "Back", а затем "Forward" возможно открыть такую страницу, при условии, что требуемые атрибуты авторизации не изменились.

Пристойное решение в admin/design/default/html/admin_page.htm назначить кнопкам Выход событие onclick="forced_logout(); return false;" и добавить скрипт

<script>
  function forced_logout () {
    var agt = navigator.userAgent.toLowerCase();
    if (agt.indexOf('msie') !== -1) {
      document.execCommand('ClearAuthenticationCache', 'false');
      window.location = '{$site|escape}';
    } else if (window.crypto && typeof window.crypto.logout === 'function') {
      window.crypto.logout();
      window.location = '{$site|escape}';
    } else {
      window.location = 'dummy:dummy@/dummy';
    }
  }
</script>

Кинет выходящего на фронтэнд и сотрет кэш аутентификации.

10:56
15 мар
#
?
Сергей написал:

Jigga, а со второй проблемой не поможешь?

15:10
15 мар
#
?
htaccess написал:

Хостинг на php cgi?
Проверка в админчасти утилиты > Информация о PHP. Внизу страницы PHP variables. Строка _SERVER["REDIRECT_REMOTE_USER"] есть?
Тогда Admin.Page.php функцию check_rights после строки 249 добавим.

if ($login == '') $login = isset($_SERVER['REDIRECT_REMOTE_USER']) ? $_SERVER['REDIRECT_REMOTE_USER'] : '';

Разработчику задание исправить обновление.
Задание сделать на форуме поддержку bbcode. Tiny паршиво работает с <pre>. Зае.. код править в Редактировать HTML-исходник.

# Jigga

Msie верно.
Firefox верно.
Почему остальным навигаторам window.location = 'dummy:dummy@/dummy'? Логин:пасс dummy:dummy понятно. И уводим админа на урл /dummy? Кеш credentials навигатора ведь надо почистить урлу /admin.

Ещё скрипт могут поставить в поддиректорию сервера. Точнее надо быть.

window.location = '{$site|replace:'://':'://dummy:dummy@'|escape}{$admin_folder|escape}';
15:36
15 мар
#
?
Сергей написал:

htaccess

Строки _SERVER["REDIRECT_REMOTE_USER"] нету.

15:38
15 мар
#
?
Сергей написал:

Да можем перейти на это форум там вроди бы лучше http://imperacms.kiev.ua/

22:04
18 мар
#
?
Андрей написал:

Ситуация похожая как у Сергея. Есть супер администратор, логин test. Проверили - никаких ограничений в правах доступа к страницам админпанели у него нет. В админку под логином test пускает на главную. Переход на любую другую страницу приводит к сообщению "У вас нет прав доступа к этой странице".

Информация о PHP посмотреть не можем - не пускает супер админа на эту страницу.

Создали на сайте в папке админпанели скрипт a.php с командой phpinfo(). В результатах его работы строки _SERVER["REDIRECT_REMOTE_USER"] нет. Есть строка _SERVER["REMOTE_USER"].

Обнаружили еще вот что. Когда открыть страницу http://сайт/admin/index.php?section=ИмяМодуля - сообщение "У вас нет прав доступа к этой странице".

Если открыть страницу http://сайт/admin/?section=ИмяМодуля - пускает и работает. Но каждый раз вручную удалять из урла index.php не выход.

Какое решение? Ссылку на сайт и ключи доступа сообщил в обратной связи. Посмотрите.

22:11
18 мар
#
?
Андрей написал:

Забыл сказать. Еще такое. Браузер Опера. Открываем http://сайт/admin/index.php?section=ИмяМодуля и часть страницы успевает прогрузиться, а только спустя полсекунды выскакивает окно авторизации. При этом прогрузка страницы замирает до завершения авторизации.

22:45
18 мар
#
?
Андрей написал:

Грешил на .htaccess в корне сайта. Убрал на время этот файл. Ничего не поменялось. Значит проблема не mod_rewrite и не правил доступа к файловой структуре сайта.

Пробовал занулить метод check_rights в Admin.Page.php. Первой строкой сделал $rights = array(); return true;
Админка заработала с любыми урлами. Но админы все заимели полные права. Не выход.

Заметил в админке с занулеными правами админов, что на урле http://сайт/admin/?section=PHPinfo есть строка _SERVER["REMOTE_USER"], а на урле http://сайт/admin/index.php?section=PHPinfo она пропадает и с ней еще несколько позиций из _SERVER[].

12:25
19 мар
#
Разработчик написал:

Ваш хостинг на веб сервере nginx. Смотрите, есть ли в панели управления хостингом пункт Конфигурирование сервера. Иначе обратитесь в техподдержку с просьбой настроить хостинг так, чтобы при наличии авторизованного админа скриптам php всегда передавался параметр REMOTE_USER.

Видимо в конфигурационном файле сервера отсутствует следующая команда:

    server {
        ...
        ...

        # конфигурация доступа для админпанели

        location ~ /admin/index\.php$ {
            ...
            ...
            fastcgi_param  REMOTE_USER  $remote_user;
            ...
            ...
        }

        # конфигурация для url 1

        location НЕКИЙ_URL_1 {
            ...
            ...
        }

        # конфигурация для url 2

        location НЕКИЙ_URL_2 {
            ...
            ...
        }

        # конфигурация для url 3

        location И_ТАК_ДАЛЕЕ {
            ...
            ...
        }

        # конфигурация для корня сайта

        location / {
            ...
            ...
        }
    }


Ведь сейчас на вашем сайте при обращении к адресу http://сайт/admin/ сначала в правильном порядке срабатывает авторизация, и только после отдача контента клиенту.

По адресу http://сайт/admin/index.php почему-то порядок нарушается, словно авторизация и отдача контента выполняются параллельно.

В обновлении движка я закрою данную лазейку (неожиданное получение контента прежде ввода пароля) для неверно настроенных хостингов. Правильнее даже сказать не то, чтобы хостинг настроен неправильно, скорее сконфигурирован по умолчанию, просто такие дефолтные настройки не учитывают, что в FastCGI режиме (когда PHP ускорен за счет параллельной обработки запросов) и Basic методе авторизации не исключена возможность отработки подчиненного запроса вперед главного.

13:23
27 мар
#
?
Андрей написал:

Хостер у себя поправил в настройках и теперь все работает. Я узнал что было в тех поддержке хостинга. Мне объяснили так:

1. по поводу проблемы в странице администратора

  • На данный момент после того как хостер поправил настройки авторизация возможна только потому что сайт теперь работает под пользователем Apache, а не пользователя домена.

2. по поводу проблемы с прайс-листом (ее в этом топике я не озвучивал, но она была)

  • Прайс лист выгружается как раз наоборот: под пользователем домена работает, а под Apache не работает.

    Дело в том что под пользователем домена сайт строго не видит или не работает .htaccess или .passwd для авторизации админа.

С хостинга предложили авторизацию для администраторов сайта делать с помощью php и хранить данные админов в mysql.

09:30
28 мар
#
?
agg написал:

По первому пункту попробывал у себя, В ie все нормально, chrome, opera, ff не очищается кэш авторизации. Добавил скрипт, который выкладывал Jigga выше, привязав его к кнопке:

В ie все работает, кэш чистится

В ff редиректит на стартовую страницу сайта, но не чистит кэш, как будто window.crypto.logout(); не срабатывает.

chrome и opera "window.location = 'dummy:dummy@/dummy' - "Вы попытались получить доступ к адресу dummy:dummy@/dummy, который сейчас недоступен. Убедитесь, что веб-адрес (URL) введён правильно, и попытайтесь перезагрузить страницу."

Меняя window.location = 'dummy:dummy@/dummy на window.location = '{$site|replace:'://':'://dummy:dummy@'|escape}';
(Исходный код window.location = 'http://dummy:dummy@имяхоста.ru/';)
редиректит, но кэш не очищается.

{literal}
  <script>
    function forced_logout () {
      var agt = navigator.userAgent.toLowerCase();
      if (agt.indexOf('msie') !== -1) {
        document.execCommand('ClearAuthenticationCache', 'false');
        window.location = '{/literal}{$site|escape}{literal}';
      } else if (window.crypto && typeof window.crypto.logout === 'function') {
        window.crypto.logout();
        window.location = '{/literal}{$site|escape}{literal}';
      } else {
        window.location = '{/literal}{$site|replace:'://':'://dummy:dummy@'|escape}{literal}';
      }
    }
  </script>
{literal}

Знатоки, где я ошибаюсь?

12:06
28 мар
#
Разработчик написал:

Андрей! Умеет техподдержка вашего хостинга перекладывать с больной головы на здоровую. Действительно, сайт лучше вернуть на работу под пользователем ДОМЕН, чем под пользователем apache. Потому что на сайте уже появились файлы (например в папке http://сайт/compiled) с атрибутами доступа RW-R--R-- (Read могут все, Write только владелец), созданные разные системными пользователями. Получили невозможность перезаписать или удалить отдельные файлы (компиляционные кеши, архивы бекапов, подгруженные фотографии товаров и т.д.).

Что касается пояснений техподдержки насчет авторизации - лапша на уши неосведомленному. У вас ранее, когда сайт работал от имени пользователя ДОМЕН, авторизация исполнялась правильно, если обращались к админпанели по адресу http://сайт/admin/ (веб сервер в этом случае увидел же .htaccess и .passwd) и не работала по адресу http://сайт/admin/index.php (почему здесь не увидел?).

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

Здесь налицо разница в конфигурационных настройках виртуального хостинга для пользователей ДОМЕН и apache. Исправить разницу может только хостер.

Предложение переделать авторизацию за счет изменения движка - просто попытка откреститься от решения проблемы. Предположим, завтра вы захотели положить на сайте свой файл example.txt и простейшим образом закрыть к нему доступ по паролю. Это базовая возможность веб сервера по ограничению доступа (.htaccess + .passwd), но у вас на хостинге она не работает как положено под пользователем ДОМЕН. Вам предложат писать какой-то скрипт и хранить пароль в MySQL?

16:08
28 мар
#
?
Андрей написал:

Объяснил тех поддержке еще раз по поводу 2 адресов с противоположным результатом авторизации. Они ответили:

Версия PHP на хостинге не имеет поддержки работы с авторизационной информацией из .htaccess и .passwd. Естественным образом скрипту http://сайт/admin/index.php недоступны такие сведения. Придумайте другое решение.

17:45
28 мар
#
Разработчик написал:

Вот так новость. Тогда почему, как только они перевели работу сайта из-под пользователя apache, сайт стал работать правильно как по одному адресу, так и по другому?

Что ж, коль гора не идет Магомеду, пойдем навстречу. Предлагаю "костыльное" решение из двух шагов.

Шаг 1: перенаправлять на рабочий адрес всех, кто знает об URL-уязвимости хостинга и ломится через нее в админпанель.

В файл http://сайт/admin/.htaccess добавим rewrite-правило внутреннего редиректа со страницы вида http://сайт/admin/index.php[?опциональные-get-параметры] на страницу вида http://сайт/admin[?опциональные-get-параметры]

    AuthName "Impera CMS admin panel"
    AuthType Basic
    AuthUserFile /****/*****/******/*******
    require valid-user

    RewriteEngine on
    RewriteRule  ^index\.php$  /admin  [R=301,NC,QSA]


Шаг 2: динамически исправить все ссылки на странице.

В конец макета страницы админпанели (файл http://сайт/admin/design/default/html/admin_page.htm), прямо перед закрывающим тегом </body> встраиваем скрипт удаления подстроки /index.php из опций href и action всех тегов <a> и <form> на текущей странице.

    <script language="JavaScript" type="text/javascript">

        // удаляем /index.php из тегов a
        jQuery('a[href]').each(function () {
            this.href = this.href.replace(/^(http:\/\/[a-z0-9\._\-]+\/admin)\/index\.php/i, '$1');
        });

        // удаляем /index.php из тегов form
        jQuery('form[action]').each(function () {
            this.action = this.action.replace(/^(http:\/\/[a-z0-9\._\-]+\/admin)\/index\.php/i, '$1');
        });

    </script>


Вообще говоря, это рискованное решение, так как не гарантирует 100% защиты.

Написание ответа

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


Обратите внимание! Для противодействия спаму новые посты форума проявляются с задержкой от нескольких минут, пока не пройдут модерацию.


Хостинг для сайта

Хостинг для интернет магазина

Svai.net

Украина
г. Черкассы
5+ Заказать

TutHost.ua

Украина
г. Киев
Заказать

Mirohost.net

Украина
г. Киев
? Заказать

HyperHosting.com.ua

Украина
г. Винница
i подробнее Заказать

Agava.ru

Россия
г. Москва
Заказать

Ukraine.com.ua

Украина
г. Киев
5 Заказать
Импераготовасотрудничатьс провайдерами Важно Учтите Этот список перечисляет лишь некоторых хостинг-провайдеров, у которых существуют специальные тарифные планы для интернет магазинов, а сам список не означает, что другие провайдеры чем-то хуже.

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

Демо Главная Хронология Соглашение Материалы Контакты