Обнаружил ошибки:
1. Когда нажимаешь на кнопку выход с админки, как бы выходишь, но когда заходишь заново вводишь любой логин и пароль тебя впускает в админку.
2. После обновления до Последней версии, в администраторской части добавляешь админа, а потом пытаешся войти под новым тебя не пускает в админку, с рабатывает только первоначальный логин и пароль.
Помогите решить проблему номер 2, так как очень нужно.
Игрался с правами доступа не помогает.
В хроме пробовали? Он не чистит кэш и возвратиться даст под липой.
Из мануала 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>
Кинет выходящего на фронтэнд и сотрет кэш аутентификации.
Хостинг на 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}';
Да можем перейти на это форум там вроди бы лучше http://imperacms.kiev.ua/
Ситуация похожая как у Сергея. Есть супер администратор, логин test. Проверили - никаких ограничений в правах доступа к страницам админпанели у него нет. В админку под логином test пускает на главную. Переход на любую другую страницу приводит к сообщению "У вас нет прав доступа к этой странице".
Информация о PHP посмотреть не можем - не пускает супер админа на эту страницу.
Создали на сайте в папке админпанели скрипт a.php с командой phpinfo(). В результатах его работы строки _SERVER["REDIRECT_REMOTE_USER"] нет. Есть строка _SERVER["REMOTE_USER"].
Обнаружили еще вот что. Когда открыть страницу http://сайт/admin/index.php?section=ИмяМодуля - сообщение "У вас нет прав доступа к этой странице".
Если открыть страницу http://сайт/admin/?section=ИмяМодуля - пускает и работает. Но каждый раз вручную удалять из урла index.php не выход.
Какое решение? Ссылку на сайт и ключи доступа сообщил в обратной связи. Посмотрите.
Забыл сказать. Еще такое. Браузер Опера. Открываем http://сайт/admin/index.php?section=ИмяМодуля и часть страницы успевает прогрузиться, а только спустя полсекунды выскакивает окно авторизации. При этом прогрузка страницы замирает до завершения авторизации.
Грешил на .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[].
Ваш хостинг на веб сервере 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 методе авторизации не исключена возможность отработки подчиненного запроса вперед главного.
Хостер у себя поправил в настройках и теперь все работает. Я узнал что было в тех поддержке хостинга. Мне объяснили так:
1. по поводу проблемы в странице администратора
2. по поводу проблемы с прайс-листом (ее в этом топике я не озвучивал, но она была)
С хостинга предложили авторизацию для администраторов сайта делать с помощью php и хранить данные админов в mysql.
По первому пункту попробывал у себя, В 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}
Знатоки, где я ошибаюсь?
Андрей! Умеет техподдержка вашего хостинга перекладывать с больной головы на здоровую. Действительно, сайт лучше вернуть на работу под пользователем ДОМЕН, чем под пользователем apache. Потому что на сайте уже появились файлы (например в папке http://сайт/compiled) с атрибутами доступа RW-R--R-- (Read могут все, Write только владелец), созданные разные системными пользователями. Получили невозможность перезаписать или удалить отдельные файлы (компиляционные кеши, архивы бекапов, подгруженные фотографии товаров и т.д.).
Что касается пояснений техподдержки насчет авторизации - лапша на уши неосведомленному. У вас ранее, когда сайт работал от имени пользователя ДОМЕН, авторизация исполнялась правильно, если обращались к админпанели по адресу http://сайт/admin/ (веб сервер в этом случае увидел же .htaccess и .passwd) и не работала по адресу http://сайт/admin/index.php (почему здесь не увидел?).
Более того, прайс-лист скачивается с клиентской стороны, авторизация к нему вообще не имеет отношения. Тем не менее, под пользователем apache скачивание прайс-листа перестало работать, а под другим пользователем работало.
Здесь налицо разница в конфигурационных настройках виртуального хостинга для пользователей ДОМЕН и apache. Исправить разницу может только хостер.
Предложение переделать авторизацию за счет изменения движка - просто попытка откреститься от решения проблемы. Предположим, завтра вы захотели положить на сайте свой файл example.txt и простейшим образом закрыть к нему доступ по паролю. Это базовая возможность веб сервера по ограничению доступа (.htaccess + .passwd), но у вас на хостинге она не работает как положено под пользователем ДОМЕН. Вам предложат писать какой-то скрипт и хранить пароль в MySQL?
Объяснил тех поддержке еще раз по поводу 2 адресов с противоположным результатом авторизации. Они ответили:
Версия PHP на хостинге не имеет поддержки работы с авторизационной информацией из .htaccess и .passwd. Естественным образом скрипту http://сайт/admin/index.php недоступны такие сведения. Придумайте другое решение.
Вот так новость. Тогда почему, как только они перевели работу сайта из-под пользователя 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% защиты.