Jump to content
Дизайн и модификация Invision Power Board IPBSkinsBETA
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
cyrax_02

ip.board 3.4.5: скрипт (admin/index.php) генерирует 404 ошибку

Recommended Posts

Перенёс сайт с форумом на новый 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. Из-за неочищенного кэша (только как его очистить (вернее, что именно чистить) без доступа в админку ?)

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites
В админке нет чпу. Перезалейте еще раз папку admin и проверьте куда форма авторизации отправляет запрос.

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

 

Что имеем:

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

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

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

 

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

Share this post


Link to post
Share on other sites
В админке нет чпу. Перезалейте еще раз папку admin

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

 

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

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

Edited by cyrax_02

Share this post


Link to post
Share on other sites

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 включены... В админке...

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Проверьте права на папку админки и файла 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, но не находит...

Share this post


Link to post
Share on other sites

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

  • Upvote 1

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Да, причина в 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 ?

Share this post


Link to post
Share on other sites

Используйте 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'] ), там есть вторая часть с константой из АЦ для нормального определения окружения - ее в вашем случае будет достаточно.

Share this post


Link to post
Share on other sites
(надеюсь $_SERVER['SCRIPT_FILENAME'] у вас настроен)

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

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...