Перенёс сайт с форумом на новый VPS. Путь расположения сайта изменился. В корневом conf_global.php все пути поправил.

Результат: форум работает нормально, вход по паролю тоже работает без проблем.

 

Но при попытке входа в админку получаем 404 ошибку. Но не от веб-сервера, а от главного админского скрипта - admin/index.php:

Ошибка 404: запрошенная страница не найдена

[#404]

К сожалению, не удалось найти запрашиваемую вами страницу. Пожалуйста вернитесь на главную страницу форума.

Полезные ссылки

Разделы помощи

Связь с администрацией форума

 

404 ошибку возвращает вот этот фрагмент кода из метода ipsRegistry::init()

/* Have we entered an incorrect FURL that has no match? */
if ( ipsRegistry::$settings['use_friendly_urls'] AND self::$_noFurlMatch === true )
{
self::getClass('output')->showError( 'incorrect_furl', 404, null, null, 404 );
}
else if( isset(ipsRegistry::$request['act']) AND ipsRegistry::$request['act'] == 'rssout' )
{
self::getClass('output')->showError( 'incorrect_furl', 404, null, null, 404 );
}

Дальше отслеживать вызовы сил не хватило. Без phpStorm - это какое-то извращение...

Поле $_noFurlMatch мне ни о чём не говорит...

 

Возможные причины:

1. Где-то в глубине админки прямо прописаны старые пути к админке

2. Из-за неочищенного кэша (только как его очистить (вернее, что именно чистить) без доступа в админку ?)

Без phpStorm - это какое-то извращение.

Только блокнот, только хардкор.

 

404 ошибку возвращает вот этот фрагмент кода из метода ipsRegistry::init()

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

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

До авторизации в админке дело не доходит. Админский скрипт сразу возвращает свою 404 ошибку.

 

Что имеем:

1) Запускается админский скрипт admin/index.php

2) Этот скрипт запускает мой единственный собственный хук (который не должен запускаться в админке)

3) Настройка ipsRegistry::$settings['use_friendly_urls'] действительно включена => url, естественно, и не находится

 

Т.е. проблема локализуется в нечто, что заставляет работать этот админский скрипт как обычный форумовский. Вернее, окружение этот скрипт получает форумовское...

В админке нет чпу. Перезалейте еще раз папку admin

Сверил с оригинальным дистрибутивом - те же самые файлы в /admin. Т.е. в коде /admin/sources/base/ipsRegistry.php действительно идёт проверка на дружественные url. Согласен, что в коде админки дружественные url упоминаться не должны, но это факт. Такие исходники. И эти исходники на старом сервере работают нормально. На новом - глючат.

 

И управление передаётся именно админскому скрипту - /admin/index.php, а не главному форумовскому (/index.php).

Куки и кэш браузера полностью вычистил - та же самая проблема.

Изменено 3 ноября 20169 г пользователем cyrax_02

die('<pre>'.print_r(ipsRegistry::$settings, true).'</pre>');

Получаем:

Array
(
   [b][base_url] => http://www.site.ru/forum/index.php?
   [_original_base_url] => http://www.site.ru/forum[/b]
   [b][this_url] => http://www.site.ru/forum/admin/[/b]
   [query_string_safe] => 
   [query_string_formatted] => 
   [b][_admin_link] => http://www.site.ru/forum/admin/index.php[/b]
   [su_max_chars] => 500
   [su_max_replies] => 100
   [su_enabled] => 1
   [fbc_xdlocation] => http://www.site.ru/community/interface/facebook/xd_receiver.php
   [fb_req_perms] => email,publish_stream,read_stream
   [js_main] => http://www.site.ru/forum/admin/js/
   [public_dir] => http://www.site.ru/forum/public/
   [cache_dir] => http://www.site.ru/forum/cache/
   [base_url_ns] => http://www.site.ru/forum/index.php?/index.php?
   [base_url_with_app] => http://www.site.ru/forum/index.php?app=forums&
   [js_base] => http://www.site.ru/forum/index.php?
   [img_url] => http://www.site.ru/forum/public/style_images/master
   [img_url_no_dir] => http://www.site.ru/forum/public/style_images/
   [public_cdn_url] => http://www.site.ru/forum/public/
   [css_base_url] => http://www.site.ru/forum/public/
   [js_base_url] => http://www.site.ru/forum/public/
   [emoticons_url] => http://www.site.ru/forum/public/style_emoticons/<#EMO_DIR#>
   [mime_img] => http://www.site.ru/forum/public
)

В этой переменной все пути корректные, за исключением пути к uploads. Где он прописывается - неизвестно, но после получения доступа к админке его можно будет без проблем подкорректировать из админки. В любом случае этот путь к проблеме отношения не имеет.

 

И самое главное - значение переменной:

[friends_enabled] => 1

Т.е. furl включены... В админке...

Проверьте права на папку админки и файла index.php. Возможно и то, что у папки не хватает необходимых прав на чтение или выполнение.

Чпу можете оставить в покое, он не причем. На работу админке он не влияет, а у вас отрабатывает не admin а front, т.е. сервер не может найти или получить доступ к /admin/index.php и считает этот адрес не существующем. Отключите реврайт в htaccess и скорее всего получите сообщение от сервера not found или forbiden.

Проверьте права на папку админки и файла index.php. Возможно и то, что у папки не хватает необходимых прав на чтение или выполнение.

Права в порядке - 755, владелец - пользователь, от имени которого запускаются процессы php-fpm.

Да и если бы не хватало прав на какие-то операции, в логах были бы соответствующие сообщения веб-сервера

Если искусственно ужать права на /admin/index.php до 0000, то начинаю получать в логах такое сообщение: .../admin/index.php" failed (13: Permission denied)

 

у вас отрабатывает не admin а front, т.е. сервер не может найти или получить доступ к /admin/index.php и считает этот адрес не существующем.

Как fastcgi-сервер (php-fpm) не может найти или получить доступ к /admin/index.php, если этот скрипт физически выполняется. Именно /admin/index.php, а не front-овый /index.php. Ставлю в /admin/index.php в самом вверху строку "die("OK")" - перезагружаю веб-сервер - получаю в браузере "OK".

 

Отключите реврайт в htaccess и скорее всего получите сообщение от сервера not found или forbiden.

У меня nginx. Отключил вообще все rewrite'ы в конфиге, перезагрузил nginx. Итог:

- при запросе .../forum/admin/ получаю ту же самую ошибку 404 (генерируемую скриптом /admin/index.php)

- при запросе .../forum/admin/index.php получаю 200 ответ, при этом загружается главная страница форума, но без всяких стилей и картинок

 

Т.е. что имеем:

1. Отрабатывает админский скрипт /forum/admin/index.php

2. Отрабатывает метод ipsRegistry::init() из файла /admin/sources/base/ipsRegistry.php

3. Отрабатывает вот этот фрагмент кода, возвращающий 404 ошибку:

/* Have we entered an incorrect FURL that has no match? */
if ( ipsRegistry::$settings['use_friendly_urls'] AND self::$_noFurlMatch === true )
{
   self::getClass('output')->showError( 'incorrect_furl', 404, null, null, 404 );
}
else...

Т.е. в момент выполнения этого кода либо furl должны быть отключены, либо для включенных furl он должен корректно находить furlMatch, но не находит...

Вы не в ту сторону смотрите. Этот код отрабатывает только для IPS_AREA public, оставьте в покое furl. Если он выполняется значит форум загружает фронтенд а не админ окружение. Еще раз проверьте название папки CP_DIRECTORY в initdata.php и сделайте дамп $_SERVER['PHP_SELF'].

Замените фрагмент на admin - в моём сообщении и в своём. Это админка моя такая. Не углядел.

Больше не буду ничего выкладывать на форум - обязательно что-нибудь вылезет...

Да, причина в PHP_SELF. Если эта переменная пуста, то админка начинает глючить, если равна /forum/admin/index.php, то работает нормально.

 

В свою очередь, при наличии заголовка PATH_INFO (т.е. если в конфигурации nginx прописать директиву fastcgi_param PATH_INFO ..., пусть даже с пустым значением) nginx (или php) принудительно устанавливает переменную PHP_SELF в PATH_INFO (если при этом в конфигурации nginx дополнительно прописать директиву fastcgi_param PHP_SELF ..., она будет перезаписана значением PATH_INFO) Если заголовок PATH_INFO fastcgi-серверу не передавать, то в переменную PHP_SELF nginx запишет корректное значение /forum/admin/index.php и админка будет работать корректно.

 

Т.е. для решения проблемы необходимо выполнить один из следующих пунктов:

а) включить (не отключать) php-опцию cgi.fix_pathinfo - в этом случае php присвоит переменной PHP_SELF корректное значение (равное SCRIPT_NAME), не зависимо от значения PATH_INFO. Но при этом может быть открыта вот эта уязвимость

б) передавать fastcgi-серверу переменную PATH_INFO со значением, равным SCRIPT_NAME. В этом случае будет иметь место нарушение спецификации

в) не передавать fastcgi-серверу переменную PATH_INFO - в этом случае nginx отправит fastcgi-серверу корректный PHP_SELF (равный SCRIPT_NAME)

 

Здесь самым "правильным" является 3-й вариант.

Возникает вопрос, можно ли решить проблему с отключенным cgi.fix_pathinfo и с передачей fastcgi-серверу пустого PATH_INFO ?

Используйте str_replace( substr( DOC_IPS_ROOT_PATH, 0, -1 ), '', $_SERVER['SCRIPT_FILENAME'] ) вместо $_SERVER['PHP_SELF'] (надеюсь $_SERVER['SCRIPT_FILENAME'] у вас настроен)

Или удалите это условие preg_match( "#/" . CP_DIRECTORY . "(/|$)#", $_SERVER['PHP_SELF'] ), там есть вторая часть с константой из АЦ для нормального определения окружения - ее в вашем случае будет достаточно.

(надеюсь $_SERVER['SCRIPT_FILENAME'] у вас настроен)

Настроен. Только исходники менять нельзя. Некошерно это (после очередного обновления всё затерётся).

 

Остановился вот на этом варианте:

в) не передавать fastcgi-серверу переменную PATH_INFO - в этом случае nginx отправит fastcgi-серверу корректный PHP_SELF (равный SCRIPT_NAME)

 

Всё-таки, обозначенная проблема (пустой PHP_SELF) - это проблема взаимодействия nginx и php-fpm, но никак не проблема IP.Board.

PHP_SELF должен передаваться fastcgi-серверу, согласно спецификации.

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