Джумла ошибка 403

0 Пользователей и 1 Гость просматривают эту тему.

  • 13 Ответов
  • 19212 Просмотров

Здравствуйте!
Столкнулся с такой проблемой:
Переехал на днях на другой хостинг. При входе в панель управления (после ввода логина и пароля) появляется ошибка 403 forbidden. Самое интересное, что эта ошибка появляется только в браузере Firefox. В других браузерах вход в админку осуществляется без проблем.
Разговаривал с хостером — они говорят, что с настройками хостинга всё в порядке.

С правами на папки и файлы Joomla всё в порядке. В браузере forefox никаких дополнений не установлено, настройки cookie — в порядке, кеш чистил. Также чистил кеш DNS в компьютере. Сами новые DNS-ки и IP на домен успешно встали после переезда.
Вероятность того, что мой компьютер заражен — минимальна. Только что проверил всевозможными антивирусными сканерами.

Где-то читал, что ошибка 403 может выдаваться из-за насроек apache у хостера, если это так, почему же тогда только в одном браузере выдаётся, а не во всех… — это вопрос.
Устал проблему искать, никак найти не могу. Но причина есть — иначе быть не может.
Для меня крайне важно использовать браузер Firefox для администрирования своего сайта, поэтому прошу вас помочь.
Поделитесь соображениями.

С уважением к вам.

« Последнее редактирование: 13.08.2013, 12:21:22 от b2z »

Записан

Подожди еще день-два, или пропиши в hosts IP к домену. Было после переезда сайта, в Opera открывался новый хостинг, а в ФФ старый.Проверял по IP.

Так и не заработало… Я не особо разбераюсь в принципах работы браузера Firefox. А из-за самого хостинга может быть такое, что Firefox выдаёт ошибку 403? Может быть этот браузер так своеобразно реагирует на какие-то настройки сервера? Чисто теоретически может быть такое?

Так и не заработало… Я не особо разбераюсь в принципах работы браузера Firefox. А из-за самого хостинга может быть такое, что Firefox выдаёт ошибку 403? Может быть этот браузер так своеобразно реагирует на какие-то настройки сервера? Чисто теоретически может быть такое?

Может, если прописать директиву/настройки для User-Agent Firefox .
п.с.
А с другого компа пробовал?

« Последнее редактирование: 12.08.2013, 18:33:49 от draff »

Записан

Может, если прописать директиву/настройки для User-Agent Firefox .

Нет, с другого компьютера не пробовал. Возможности нет.

А где это директива User-Agent находится? Не в about:config случайно?

Ну обычно в .htaccess , и может быть в JavaScript.

Не так давно было похожее с FF… набери/убери перед адресом www :)

Сейчас идет массовый брутфорс пароля к админке у многих хостеров. В связи с этим хостеры закрывают доступ админке. Недавно видел тему, что один хостер(мастерхост вроде) открыл доступ к админке, но передупреждает, что для доступа нужно использовать любой браузер кроме огнелиса….

Записан

Разработка, доработка расширений для Joomla!

Нет, с другого компьютера не пробовал. Возможности нет.

Есть еще вариант- перемести в другую папки Profiles.
Находятся в C:\Document and Settings\Admin\Application Data\Mozilla\FireFox\Profiles and
C:\Document and Settings\Admin\Local Settings\Mozilla\Application Data\Mozilla\FireFox\Profiles

Всем спасибо за ответы, но у меня что-то другое похоже. Вот что стало прощупываться:
Зашёл из-под учётной записи администратора, запустил Firefox, набрал адрес админки, ввел логин и пароль — вход выполнен!
А вот из-под учётной записи пользователя — по-прежнему ошибка 403. Но «лёд тронулся» — я рад!
По крайней мере, чувствую, что не всё так критично. Подскажите, в чём беда? Моих знаний не хватает, чтобы определить. Впервые с таким сталкиваюсь.

Проверяй еще права на папку и путь /tmp .Чтобы соответствовало Document Root
А так- более всего обновились DNS , удалился кеш в браузере, очистилась таблица _session

Открыл общий доступ ко всем папкам и файлам Firefox, включая папки и файлы по адресу C:\Document and Settings\Admin\Application Data\Mozilla. Пробовал переустанавливать браузер даже. Ни в какую не хочет работать из-под учетной записи пользователя. Ошибка 403, и всё тут!
Проверил все пути jooml’ы — всё нормально. Document root всё соответствует.
Теряю надежду.

Попробуй таки переместить указанную папку Profiles. Даже когда удаляешь программу, настройки браузера остаются .А потом после новой установки браузера, старые настройки снова используются.
 И очисти в БД таблицу _session
п.с.
А что в логах хостинга?

« Последнее редактирование: 13.08.2013, 09:34:34 от draff »

Записан

Попробуй таки переместить указанную папку Profiles.

Получилось! Надо было сразу draff’a слушаться, меньше бы мучился. Спасибо!

0 Пользователей и 1 Гость просматривают эту тему.

  • 13 Ответов
  • 18799 Просмотров

Здравствуйте!
Столкнулся с такой проблемой:
Переехал на днях на другой хостинг. При входе в панель управления (после ввода логина и пароля) появляется ошибка 403 forbidden. Самое интересное, что эта ошибка появляется только в браузере Firefox. В других браузерах вход в админку осуществляется без проблем.
Разговаривал с хостером — они говорят, что с настройками хостинга всё в порядке.

С правами на папки и файлы Joomla всё в порядке. В браузере forefox никаких дополнений не установлено, настройки cookie — в порядке, кеш чистил. Также чистил кеш DNS в компьютере. Сами новые DNS-ки и IP на домен успешно встали после переезда.
Вероятность того, что мой компьютер заражен — минимальна. Только что проверил всевозможными антивирусными сканерами.

Где-то читал, что ошибка 403 может выдаваться из-за насроек apache у хостера, если это так, почему же тогда только в одном браузере выдаётся, а не во всех… — это вопрос.
Устал проблему искать, никак найти не могу. Но причина есть — иначе быть не может.
Для меня крайне важно использовать браузер Firefox для администрирования своего сайта, поэтому прошу вас помочь.
Поделитесь соображениями.

С уважением к вам.

« Последнее редактирование: 13.08.2013, 12:21:22 от b2z »

Записан

Подожди еще день-два, или пропиши в hosts IP к домену. Было после переезда сайта, в Opera открывался новый хостинг, а в ФФ старый.Проверял по IP.

Так и не заработало… Я не особо разбераюсь в принципах работы браузера Firefox. А из-за самого хостинга может быть такое, что Firefox выдаёт ошибку 403? Может быть этот браузер так своеобразно реагирует на какие-то настройки сервера? Чисто теоретически может быть такое?

Так и не заработало… Я не особо разбераюсь в принципах работы браузера Firefox. А из-за самого хостинга может быть такое, что Firefox выдаёт ошибку 403? Может быть этот браузер так своеобразно реагирует на какие-то настройки сервера? Чисто теоретически может быть такое?

Может, если прописать директиву/настройки для User-Agent Firefox .
п.с.
А с другого компа пробовал?

« Последнее редактирование: 12.08.2013, 18:33:49 от draff »

Записан

Может, если прописать директиву/настройки для User-Agent Firefox .

Нет, с другого компьютера не пробовал. Возможности нет.

А где это директива User-Agent находится? Не в about:config случайно?

Ну обычно в .htaccess , и может быть в JavaScript.

Не так давно было похожее с FF… набери/убери перед адресом www :)

Сейчас идет массовый брутфорс пароля к админке у многих хостеров. В связи с этим хостеры закрывают доступ админке. Недавно видел тему, что один хостер(мастерхост вроде) открыл доступ к админке, но передупреждает, что для доступа нужно использовать любой браузер кроме огнелиса….

Записан

Разработка, доработка расширений для Joomla!

Нет, с другого компьютера не пробовал. Возможности нет.

Есть еще вариант- перемести в другую папки Profiles.
Находятся в C:Document and SettingsAdminApplication DataMozillaFireFoxProfiles and
C:Document and SettingsAdminLocal SettingsMozillaApplication DataMozillaFireFoxProfiles

Всем спасибо за ответы, но у меня что-то другое похоже. Вот что стало прощупываться:
Зашёл из-под учётной записи администратора, запустил Firefox, набрал адрес админки, ввел логин и пароль — вход выполнен!
А вот из-под учётной записи пользователя — по-прежнему ошибка 403. Но «лёд тронулся» — я рад!
По крайней мере, чувствую, что не всё так критично. Подскажите, в чём беда? Моих знаний не хватает, чтобы определить. Впервые с таким сталкиваюсь.

Проверяй еще права на папку и путь /tmp .Чтобы соответствовало Document Root
А так- более всего обновились DNS , удалился кеш в браузере, очистилась таблица _session

Открыл общий доступ ко всем папкам и файлам Firefox, включая папки и файлы по адресу C:Document and SettingsAdminApplication DataMozilla. Пробовал переустанавливать браузер даже. Ни в какую не хочет работать из-под учетной записи пользователя. Ошибка 403, и всё тут!
Проверил все пути jooml’ы — всё нормально. Document root всё соответствует.
Теряю надежду.

Попробуй таки переместить указанную папку Profiles. Даже когда удаляешь программу, настройки браузера остаются .А потом после новой установки браузера, старые настройки снова используются.
 И очисти в БД таблицу _session
п.с.
А что в логах хостинга?

« Последнее редактирование: 13.08.2013, 09:34:34 от draff »

Записан

Попробуй таки переместить указанную папку Profiles.

Получилось! Надо было сразу draff’a слушаться, меньше бы мучился. Спасибо!

When I restored my website backup and tried to enter my web page, it says:

Forbidden

You don’t have permission to access /public_html on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

How do I solve this problem?

Community's user avatar

asked Sep 1, 2016 at 21:35

AFF's user avatar

1

What it means?

It means that your web server doesn’t have the permissions to read the folder in which you have your Joomla installed.

If you have access to the folder

If you can access to your server with a client FTP like FileZilla you should be able to right-click on the folder and then edit File Permission and set the Numeric value: to 775, which should allow the webserver to read and write.

Remember to check the checkbox of Recurse into subdirectories.

If you don’t feel secure

In case nothing of the above make sense just contact your hosting provider and ask them to change the permissions of your folder.

Community's user avatar

answered Sep 2, 2016 at 0:41

borracciaBlu's user avatar

borracciaBluborracciaBlu

3,9593 gold badges32 silver badges41 bronze badges

1

but for me it didn’t work. so I googled and found following solution.
just added in .htacess file at the bottom along with «why reason» so if this will work fine and i will remove if not..

########## Attempt to solve 'Global Configuration' save issue, FTP layer issue, Media Upload issue
SecFilterEngine Off
SecFilterScanPOST Off
########## End - Attempt to solve 'Global Configuration' save issue, FTP layer issue, Media Upload issue

And it worked smoothly. :)

so the rewards goes to.. somebody named fived on Joomla community.
https://forum.joomla.org/viewtopic.php?t=265427#p1216787

answered Jan 26, 2018 at 10:53

MFarooqi's user avatar

MFarooqiMFarooqi

9965 gold badges11 silver badges26 bronze badges

I have been continuing to try to find a logical answer to this issue, continuing to search other threads to gleam a small particle of light that might realise into a solution. But I really am getting nowhere. I was hoping to take the test website to live very shortly, but I am not convinced this is such a good idea if there is no FTP layer, media management, or global configuration ability on the back end.

@Prax — I am not sure how you flag an issue up to the core team? I would have presumed that by a thread being posted here, and over the period of a week or so a considerable number of users flag up the same issue this would prompt a member of the core team to help, advise, guide, notify of known issues etc. Perhaps I am wrong. Perhaps they are overwhelmed right now.

I will continue on my path of researching any possible answers, but as a Joomla coding novice, I am not holding out much hope. What is quite frustrating is that it probably can be solved very simply! Hey-ho!

???

EDIT TO ABOVE THREAD:
I went and had a scrummage around in the Joomla! 1.5 bug tracker(found at joomlacode.org), as I guessed it was likely that other people had had this issue, and to see how the issue was developing. Here is a solution that was suggested there — add the following code to your .htaccess file, I added it at the bottom and included a little text to explain what it is doing, so it can be easily removed if there is an issue with it:

########## Attempt to solve ‘Global Configuration’ save issue, FTP layer issue, Media Upload issue
SecFilterEngine Off
SecFilterScanPOST Off
########## End — Attempt to solve ‘Global Configuration’ save issue, FTP layer issue, Media Upload issue

Now I will say that this solved not only the issue that I had with the ability to save global configuration backend, but also to access the new J!1.5 FTP layer which I so desperately wanted, and hence solved the issue with uploading media to media manager back end.

The FTP Backend settings I found to work were as following:
Enable FTP: Yes
FTP Host: ftp.yoursubdomain.yourdomain.com
FTP Port: 21
FTP Username: [email protected] (having set up an FTP user specifically for the domain or subdomain)
FTP Password: ********** (using the password relevant to the FTP user above)
FTP Root: /

What does concern me somewhat is — does setting SecFilterEngine and SecFilterScanPOST to OFF leave vulnerabilities to the website/Joomla install/host? I would really like to hear from a Joomla core member to validate if this is the fact. Is there anybody out there that could advise? If we could get guidance from higher powers (ie people who know what they are doing!), and therefore feel more comfortable testing the principle, this could possibly be a way forward?

Cheers
FiveD

I have received a zip file from someone which contain all the data for a Joomla site. And he asked me to do some CSS configurations to change the look of homepage. I unzipped the zip file an found a .sql file, a Joomla site folder and a .jpa backup file. I pasted that folder in xampp’s htdocs folder and named it as tp and then imported the sql file in newly created database and and made changes in configuration file for database.

Now when I type localhost/tp the site runs successfully, but when I type localhost/tp/administrator it gives me 403 forbidden access error. The short note is that it’s my first experience with Joomla and I don’t know how I can fix this. As mostly 403 error comes due to error in .htdocs file that’s why I am giving the the code at the end of this question.

# @package      Joomla
# @copyright    Copyright (C) 2005 - 2012 Open Source Matters. All rights reserved.
# @license      GNU General Public License version 2 or later; see LICENSE.txt
# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!
# The line just below this section: 'Options +FollowSymLinks' may cause problems
# with some server configurations.  It is required for use of mod_rewrite, but may already
# be set by your server administrator in a way that dissallows changing it in
# your .htaccess file.  If using it causes your server to error out, comment it out (add # to
# beginning of line), reload your site in your browser and test your sef url's.  If they work,
# it has been set by your server administrator and you do not need it set here.
## Can be commented out if causes errors, see notes above.
Options +FollowSymLinks
## Mod_rewrite in use.
RewriteEngine On
# Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site block out the operations listed below
# This attempts to block the most common type of exploit attempts to Joomla!
#
# Block out any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*([^)]*) [OR]
# Block out any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.
## Begin - Custom redirects
#
# If you need to redirect some pages, or set a canonical non-www to
# www redirect (or vice versa), place that code here. Ensure those
# redirects use the correct RewriteRule syntax and the [R=301,L] flags.
#
## End - Custom redirects
##
# Uncomment following line if your webserver's URL
# is not directly related to physical file paths.
# Update Your Joomla! Directory (just / for root).
##
# RewriteBase /
## Begin - Joomla! core SEF Section.
#
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
#
# If the requested path and file is not /index.php and the request
# has not already been internally rewritten to the index.php script
RewriteCond %{REQUEST_URI} !^/index.php
# and the request is for something within the component folder,
# or for the site root, or for an extensionless URL, or the
# requested URL ends with one of the listed extensions
RewriteCond %{REQUEST_URI} /component/|(/[^.]*|.(php|html?|feed|pdf|vcf|raw))$ [NC]
# and the requested path and file doesn't directly match a physical file
RewriteCond %{REQUEST_FILENAME} !-f
# and the requested path and file doesn't directly match a physical folder
RewriteCond %{REQUEST_FILENAME} !-d
# internally rewrite the request to the index.php script
RewriteRule .* index.php [L]
#
## End - Joomla! core SEF Section.
Action php /cgi-php53/php
AddHandler php53 .php
  1. Offline

    San4ozzZ

    Пользователь

    Регистрация:
    07.03.2011
    Сообщения:
    123
    Симпатии:
    0
    Пол:
    Мужской

    Доброго времени суток .
    Подскажите пожалуйста , сайт давно работает , и всё было в порядке до недавнего времени.
    решил зайти в админку , выдаёт ошибку
    Access forbidden!

    You don’t have permission to access the requested directory. There is either no index document or the directory is read-protected.

    If you think this is a server error, please contact the webmaster.

    Error 403

    biphelp.ru
    Sat Aug 3 15:36:21 2013
    Apache/2.2.23 (Gentoo) mod_dp/0.99.6 Phusion_Passenger/2.2.15 PHP/5.3.20-pl0-gentoo mod_wsgi/3.3 Python/2.7.2

  2. OlegK

    Offline

    OlegK

    Russian Joomla! Team
    Команда форума
    ⇒ Профи ⇐

    Регистрация:
    17.01.2011
    Сообщения:
    7 813
    Симпатии:
    768
    Пол:
    Мужской

    Закрывай админку и жди конца взлома админок Joomla and WP
    .htaccess в папку /administrator

    Когда нужно войти- закоментируешь.

  3. Offline

    San4ozzZ

    Пользователь

    Регистрация:
    07.03.2011
    Сообщения:
    123
    Симпатии:
    0
    Пол:
    Мужской

    обьясните пожалуйста языком как недалёкому юзеру)
    переместить файл
    .htaccess в папку /administrator и отредактировать этот файл , добавить в код

    так или нет ?

  4. OlegK

    Offline

    OlegK

    Russian Joomla! Team
    Команда форума
    ⇒ Профи ⇐

    Регистрация:
    17.01.2011
    Сообщения:
    7 813
    Симпатии:
    768
    Пол:
    Мужской

    можно и так,чтобы запутать бота :D
    А можно создать файл как обычно и вставить код.

  5. Offline

    San4ozzZ

    Пользователь

    Регистрация:
    07.03.2011
    Сообщения:
    123
    Симпатии:
    0
    Пол:
    Мужской

    так сделал , всё равно не пускает в админку (

    хостинг написал .

    сделал так же не пускает
    что не так делаю ?

    Последнее редактирование: 04.08.2013

  6. OlegK

    Offline

    OlegK

    Russian Joomla! Team
    Команда форума
    ⇒ Профи ⇐

    Регистрация:
    17.01.2011
    Сообщения:
    7 813
    Симпатии:
    768
    Пол:
    Мужской

    Удалить # перед allow

    Так мой .htaccess не дает никому зайти в админку/каталог /administrator

  7. Offline

    San4ozzZ

    Пользователь

    Регистрация:
    07.03.2011
    Сообщения:
    123
    Симпатии:
    0
    Пол:
    Мужской
  8. Offline

    romansom

    Пользователь

    Регистрация:
    21.03.2014
    Сообщения:
    68
    Симпатии:
    1
    Пол:
    Мужской

    Такая же проблема
    в .htaccess приписанно

    <Files index.php>
    order deny,allow
    deny from all
    allow from ip
    </files>

    И нет доступа
    пишет

    Access forbidden!
    You don’t have permission to access the requested directory. There is either no index document or the directory is read-protected.

    If you think this is a server error, please contact the webmaster.ru

  9. OlegM

    Offline

    OlegM

    Russian Joomla! Team
    Команда форума

    Регистрация:
    12.04.2007
    Сообщения:
    4 311
    Симпатии:
    375
    Пол:
    Мужской

    Либо дописать в строку allow from ip свой IP, либо вообще удалить этот код или файл целиком, если не нужна защита админки с помощью .htaccess

  10. Offline

    romansom

    Пользователь

    Регистрация:
    21.03.2014
    Сообщения:
    68
    Симпатии:
    1
    Пол:
    Мужской

    В строку allow from ip прописан мой внешний ip

  11. OlegM

    Offline

    OlegM

    Russian Joomla! Team
    Команда форума

    Регистрация:
    12.04.2007
    Сообщения:
    4 311
    Симпатии:
    375
    Пол:
    Мужской

    Вообще убери index.php. Ты же ВСЮ админку защищаешь, а не один этот файл.

  12. Offline

    romansom

    Пользователь

    Регистрация:
    21.03.2014
    Сообщения:
    68
    Симпатии:
    1
    Пол:
    Мужской

    А если убить файл htaccess в папке /administrator
    Что будет?какие опасности кроются?

  13. OlegM

    Offline

    OlegM

    Russian Joomla! Team
    Команда форума

    Регистрация:
    12.04.2007
    Сообщения:
    4 311
    Симпатии:
    375
    Пол:
    Мужской

    Все возможные — будут ломиться роботы, пытаться подбирать пароль и т.д. и т.п.

Поделиться этой страницей

В общем, переносили сайт, вроде все сделали по правилам, осталось подождать обновления NS, но они долго не обновлялись, поэтому за работой про сайт и забыли. Вспомнил я про него, когда заметил, что в Метрике посещаемость почему-то меньше чем обычно… Оказалось сайт часа 3 уже как числится на новом хостинге, вот только при попытке попасть на него выдается ошибка “Ошибка 403 forbidden“…

Что делать? Первая мысль – не перенесены все файлы, но вроде ок, ошибки в конфигурации? нет, все правильно, права доступа к файлам? Точно! Права доступа к файлам заданы как-то не совсем правильно, что делать? Установить права доступа на директории и файлы правильно. Как установить правильно права на файлы на хостинге? Только не 777 – это полный доступ к чтению, записи и выполнению для всех файлов и папок, а значит, что доступ к хостингу при необходимых знаниях могут получить посторонние лица, поэтому оптимальный вариант – установить права доступа к файлам – 775.

Работает.

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

Я пытаюсь администрировать существующую веб-страницу Joomla, однако кажется, что предыдущий администратор сделал что-то, что запретило мне доступ к разделу / administrator на странице. Когда я пытаюсь войти в раздел администратора с помощью sitename.com/administratorили же sitename.com/administrator/index.php, Я получил 403 Forbidden,

Я проверил содержимое сайта через FTP (который я могу получить доступ нормально), и кажется, jSecure Плагин не установлен — поэтому страница администратора должна быть доступна через /administrator, право? Файл разрешений для /administrator папки были 705, я пытался изменить их на 775, без изменений. Любые предложения, что делать?

0

Решение

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

  1. Найдите следующие файлы и переименуйте их: (если вы используете apache)
    • /.htaccess
    • /administrator/.htaccess

(если это так, у вас может быть либо код, несовместимый с текущей версией Apache, либо инструкции для явного предотвращения доступа)

  1. chmod / администратор на 777 (и немедленно вернуться, если он не работает) (в этом случае это проблема с правами доступа, просто убедитесь, что у пользователя, работающего с сайтом, есть доступ на чтение к папке / administrator и подпапкам)

  2. повторно применить пакет обновления Joomla, чтобы восстановить исходные файлы на месте (вы взломали файлы)

  3. проверьте папки / logs / и / administrator / logs, файл error.php может содержать больше информации (по крайней мере, вы знаете, Joomla работает! найти больше информации в нем)

  4. проверьте журнал ошибок вашего веб-сервера. (найти больше информации там)

0

Другие решения

Других решений пока нет …

Помогаю со студенческими работами здесь

Админка joomla
Подскажите пожалуйста, как можно реализовать простейшую админку на joomla, чтобы было просто…

Админка интернет-магазина на Joomla
Ребята! Я впервые столкнулась с админкой Joomla. Я не программист и не сис-админ. Всего лишь…

Joomla Как вернуть модуль Админка
Вобщем по случайности отключил модуль Админка, а как сейчас попасть на внутринею часть страницы…

На сайте joomla ошибка 403
Привет всем!Проблема такая.Не на один раздел сайта не могу зайти,ошибка 404,сайт на джумле.Скрин…

Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:

Table of Contents

  • Introduction: What is a 403 Error?
  • Firewall Rules
  • 403 on an Image or File
  • Caching and Nonces
  • File Permissions
  • CDN Issues
  • Corrupt/Misconfigured .htaccess file
  • Broken/Missing Plugins
  • Custom Nginx Config Rules

Introduction: What is a 403 Forbidden Error?

The 403 Forbidden error occurs when a request is made the server cannot allow. This is often due to a firewall ruleset that strictly prohibits this specific request, but other settings such as permissions may prevent access based on user rights.

When 403s occur, your server understands the request that is being made, but is refusing to comply with the request. 

That’s about all there is to it. Your request is forbidden.

Error Messaging

On Nginx a 403 looks as follows: 403 Forbidden – nginx

Other variations of a 403 include:

  • 403 – Forbidden: Access is denied
  • Error 403 – Forbidden
  • 403 – Forbidden Error – You are not allowed to access this address
  • HTTP Error 403 – Forbidden – You do not have permission to access the document or program you requested
  • 403 Forbidden – Access to this resource on the server is denied


Note

The following are all certainly possibilities for your 403 errors, however, in 90% of cases, 403 errors are caused by a firewall, caching issue, or permissions issue.

1. Firewall Rules

By far the most common reason for 403 errors is that the request you’re making is being blocked for breaking one of the firewall rules.

Unlike most other hosting providers, GridPane equips you with 1-3 different Web Application Firewall (WAF) options depending on your plan: –

  1. 6G WAF
  2. 7G WAF
  3. ModSecurity

Usually, 403s are a good thing. In most cases, these types of requests are malicious in nature and the firewall blocks those from even reaching your application (WordPress website). However, WordPress is a vast ecosystem of different functionality and false positives can and do occur.

The quickest way to discover if your 403 error is being caused by a WAF is to simply turn it off and try to reproduce the issue. If the 403 no longer occurs, this is a WAF issue.

You can find out the specific reason the request is being blocked by checking the log. This is available directly inside the security tab at the bottom of the settings.

Once you know the cause, you can begin crafting an exclusion that is fairly straightforward, and fully documented in the links above.

Example

Here’s an example of a request that resulted in a 403 error with the 7G WAF:

website.com/wp-admin/admin.php?page=seopress-google-analytics&code=4/0AY0eSoaWlA&scope=https://www.googleapis.com/auth/analytics.readonly

This request broke 2 rules, as detailed by this result in the 7G WAF log:

[17/Nov/2020:15:05:35 +0000] [":bad_querystring_12::bad_request_15:"] 199.199.199.199 yourdomain.com "GET /wp-admin/admin.php?page=seopress-google-analytics&code=4/0AY0e-g44ZrE9024kffJQ2LbRdRxVLOQgAruyU9wAHI1jYFCDaUo10xmwW5rpilPzqNKOSoaWlA&scope=https://www.googleapis.com/auth/analytics.readonly HTTP/1.1" 403 "https://accounts.google.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36"

Using this information we can create a rule to exclude these two results by targeting “page=seopress-google-analytics&code” and adding an exclusion for both errors like so:

set $exclusion_rule_match "";
if ( $args ~* ^page=seopress-google-analytics&code ) {
set $exclusion_rule_match 15;
}
if ($bad_request_7g = $exclusion_rule_match) {
set $7g_drop_bad_request 0;
}
set $exclusion_rule_match "";
if ( $args ~* ^page=seopress-google-analytics&code ) {
set $exclusion_rule_match 12;
}
if ($bad_querystring_7g = $exclusion_rule_match) {
set $7g_drop_bad_query_string 0;
}

Please see the full articles for a complete tutorial.

403 on an Image or File

Following on from the above section, images or files may sometimes return a 403 for a seemingly unknown reason.

These can be difficult to troubleshoot because it’s really not obvious what the cause is, however, this is almost certainly either the 7G firewall.

A couple of examples to illustrate this are images/files that contain either the word “Specialist” or the word “Conference”. 

The reason these get flagged are due to the word conference containing “conf” (which is a file name extension), and specialist containing the name of a commonly spammed pharmaceutical.

The quickest solution is to rename the file, or to edit out that specific line or word in the firewall. Our documentation has details how to do this here:

Using the GridPane 7G Web Application Firewall

2. Caching and Nonces

The second most common issue outside of a firewall rule being is broken is where caching is interfering with a form (such as a contact form, or payment gateway form). Here, the form uses what’s called a “nonce” (a security token which is a number or random string used only once), which exists for a set period of time (12 hours is common) after which it changes to something new. Once change occurs, the cache may serve the outdated nonce and this results in an error.

If you have a form or any functionality that makes use of a nonce, these can break and return 403 errors if the cache isn’t cleared once the nonce expires.

In many cases, nonces last 12-24 hours. For example, the Gravity forms payment gateway has a 12-hour nonce and can result in 403 errors if cached for over 12 hours.

If clearing the cache allows your functionality to begin operating correctly again, this is a caching issue.

Plugins we know of that may experience cache related issues are:

  1. Gravity Forms Payments
  2. Divi Forms
  3. Caldera Forms

In these cases, there are a couple of different solutions.

Solution 1. Exclude the page from the cache

If you exclude the page from the cache, the cache will not interfere with the nonce and all forms will operate as normal. 

Please see the following guide on how to exclude a page from your website’s cache (Nginx only):

Exclude a page from server caching

Solution 2. Reduce Cache TTL

If you’re using Redis Page Caching, the default TTL is 30 days. If you’re experiencing nonce related form failures, you can reduce the cache time to avoid these in the future.

This requires running a single GP-CLI command. To do so, you will need to SSH into your server. Please see the following guides to get started:

The command for altering the default caching TTL is as follows:

gp stack nginx redis -site-cache-valid {accepted.value} {site.url}

Run the following command to reduce cache time to 6 hours (replacing site.url with your domain name):

gp stack nginx redis -site-cache-valid 21600 site.url

The time length has to be entered in seconds. In this case, 6 hours = 21600 seconds.

For 10 hours, run the following:

gp stack nginx redis -site-cache-valid 36000 site.url

For more details, please see this Redis Page caching section in the Configure Nginx article:

Set caching expiry time for all successful requests going into Redis SRCache page cache

3. Permissions

403 errors can also be caused by incorrect permissions settings. This can sometimes occur when migrating a website over to GridPane.

Fortunately, we have a quick fix self-help tool that can help reset your website to the correct permissions very quickly and with minimal fuss. To fix your websites permissions, please see this article:

Self Help Tools: Reset Application File Permissions

4. CDN Issues

If the 403 forbidden errors you’re experiencing are specific to your assets (images, CSS, and JS files), and you’re using a delivery network (CDN) for your website, try temporarily disabling this service to see if this is at the root of your issue.

If it isn’t, this is likely firewall related, possibly due to 7G Bad Bot rule #5.

5. Corrupt/Misconfigured .htaccess File

Nginx doesn’t use .htaccess, so this error is OpenLiteSpeed specific for GridPane hosted websites.

This is a very powerful file, and if corrupted or misconfigured, this could result in a 403 error for your website.

Fortunately, GridPane keeps a backup copy that you can use in the case of an emergency:

You can get your website back up and running by replacing the current .htaccess file with the contents of the .htaccess.save file.

This is easier done over SFTP. To connect to your server over SFTP, please see either one of the following articles:

Connect to a GridPane Server by SFTP as System User

Connect to a GridPane Server by SFTP as Root user

Step 1

Once connected, first save a copy of the .htaccess.save file to your computer.

Step 2

Next, rename the corrupt .htaccess file to .htaccess.bad

Step 3

Next, rename .htaccess.save to .htaccess and then check your website.

Step 4

You can now re-upload the .htaccess.save to your server again for safekeeping, and delete the .htaccess.bad file.

6. Broken/Missing Plugin Files

If none of the above is the cause for your 403 error, then this could be the work of a broken or missing plugin file.

To check, connect to your server over SFTP (see the links in part 5 above to get started) and rename the plugins folder (located at site.url/htdocs/wp-content/plugins) to plugins-off.

Next, check your website and see if the 403 error is occurring. If not, then you know the root cause is one of the plugins on your website.

Rename the plugins-off directory back to plugins, and then do the same for each of your individual plugin folders, renaming them one by one until you find the one responsible.

7. Custom Nginx Configurations

Sometimes plugin authors can be rather careless with their Nginx recommendations, documenting broad Nginx rules that can result in unexpected/undesirable behavior such as blocking specific types of files altogether, or blocking them when not logged into the website.

You may have added custom configuration rules to Nginx via .conf files in your  /var/www/site.url/nginx directory.

For example:

/var/www/example.com/nginx/ithemes-security-main-context.conf

Custom configurations that affect ALL websites on the server may also have been added in these directories:

/etc/nginx/extra.d/
/etc/nginx/conf.d/

Be sure to check this directory for any Nginx configuration files that you or your team members may have added (be sure to ask them so you know what to look for), and review them for code that could prevent access to page or file that your getting your 403 forbidden error.


  1. BalamutMAN

    Offline

    BalamutMAN

    Недавно здесь

    Регистрация:
    13.01.2012
    Сообщения:
    18
    Симпатии:
    0
    Пол:
    Мужской

    Здравствуйте ув форумчане, мой сайт работает на Joomla 3.5 и все было хорошо, но вдруг один из дочерних пунктов меню стал отдавать ошибку 403 (В доступе на страницу отказано, все остальные пункты меню работают корректно и до него и после него. Где ошибка и что ее вызывает понять не могу, подскажите пожалуйста как проанализировать эту ошибку и понять что ее вызывает?

    index.php работает корректно

    как мне найти конкретную папку или файл ответственный за вывод одного конкретного пункта меню?

    есть достуа к ftp , я бы поменял права к пункту меню или статье если бы знал как их найти через ftp…

  2. OlegM

    Offline

    OlegM

    Russian Joomla! Team
    Команда форума

    Регистрация:
    12.04.2007
    Сообщения:
    4 311
    Симпатии:
    375
    Пол:
    Мужской

    1. Определить в настройках пункта меню, какому компоненту принадлежит данный пункт меню. Например, если в URL option=com_content — то com_content. Это менеджер статей (материалов).
    2. Проверить права доступа к этому компоненту.
    3. Проверить права доступа к определенному функционалу этого компонента.

    Например, у статьи (материала) доступ может быть ограничен на уровне конкретной статьи, её категории, или всего компонента.

    Можно в общих настройках сайта включить Отладку сайта, а затем просмотреть отчет о правах доступа в Пользователи Группы Отчёт о проверке прав доступа

    Лучше покажи URL пункта меню.

    Это бред. Все права доступа хранятся в базе данных. «Здесь Вам не тут, а Joomla — не битрикс», чтобы изменением доступа к файлу менялся уровень доступа. :)


    danem и BalamutMAN нравится это.


  3. BalamutMAN

    Offline

    BalamutMAN

    Недавно здесь

    Регистрация:
    13.01.2012
    Сообщения:
    18
    Симпатии:
    0
    Пол:
    Мужской

    Спасибо за помощь!
    1. com_content
    2. drwxr-xr-x
    3. public установлено у пункта меню и статьи

    зашел в «Отчёт по отладке прав доступа для группы #1, Public»
    там у всех все одинаково…

    обратите внимание что пункты меню верхнего уровня и нижнего работают..

    Последнее редактирование: 19.07.2016

  4. OlegK

    Offline

    OlegK

    Russian Joomla! Team
    Команда форума
    ⇒ Профи ⇐

    Регистрация:
    17.01.2011
    Сообщения:
    7 813
    Симпатии:
    769
    Пол:
    Мужской

    Перешел по ссылке и вижу предупреждение о Мошенничестве

    Вложения:

    • j.JPG

      j.JPG
      Размер файла:
      44.2 КБ
      Просмотров:
      1


  5. BalamutMAN

    Offline

    BalamutMAN

    Недавно здесь

    Регистрация:
    13.01.2012
    Сообщения:
    18
    Симпатии:
    0
    Пол:
    Мужской

    возможно это потому-что www.crdf.fr показывает что есть вирусы на сайте, все никак не могу добиться от них удаления сайта из базы (virustotal показывает что сайт чист)

  6. OlegM

    Offline

    OlegM

    Russian Joomla! Team
    Команда форума

    Регистрация:
    12.04.2007
    Сообщения:
    4 311
    Симпатии:
    375
    Пол:
    Мужской

    Лучший ответ

    Так это у тебя серверная ошибка. Попробуй переименовать пункт меню — audiotmp вместо audio, например.

    И смотри ограничение доступа в .htaccess или в настройках сайта на хостинге.


  7. BalamutMAN

    Offline

    BalamutMAN

    Недавно здесь

    Регистрация:
    13.01.2012
    Сообщения:
    18
    Симпатии:
    0
    Пол:
    Мужской

    Олег! Лучи добра тебе и огромное спасибо! Переименовал-заработало, переименовал обратно — написало что конфликт с подпапкой на сервере (положил папку с названием аудио) удалил ее и вуаля!

  8. OlegM

    Offline

    OlegM

    Russian Joomla! Team
    Команда форума

    Регистрация:
    12.04.2007
    Сообщения:
    4 311
    Симпатии:
    375
    Пол:
    Мужской

    Ну и ладненько. с|:)
    И все равно — пока своими глазами не увидишь — хрен знает, о чем речь и куда копать.

    «Порой метод тыка творит чудеса»

  9. Offline

    danem

    Недавно здесь

    Регистрация:
    18.06.2013
    Сообщения:
    4
    Симпатии:
    1
    Пол:
    Мужской

    В Яндекс вэбмастере стояла 403 ошибка на главной странице, индексированию не подлежала. Все перерыл не как не мог избавится. Статьи пересматривал но видел фигу. После этого топика, спецом проверил статью от пункта меню — права на админа стаяли. Блин, и это вот промашка вэбмастера с опытом в 16 лет. Спасибо, Олегу!

Поделиться этой страницей


Форумы Joomla! CMS

Joomla creates/raises a 403 event, when trying to access a protected article. So editing the file System / error.php or within the template itself did not work. Also the other solutions in .htaccess or httpd.conf using ErrorDocument did not work.

I also tried the code this-> error-> getCode () == ‘403’, but it doesn’t fire.

The only solution I found was to modify the HTML view for the articles to redirect to an article where I show a login and a personalized message.

The file to modify is components / com_content / views / article / view.html.php line 134 to 139

Joomla 3.9.20

The code to replace is the following:


 // Check the view access to the article (the model has already computed the values).
                if ($ item-> params-> get ('access-view') == false && ($ item-> params-> get ('show_noauth', '0') == '0'))
                {
                        $ app-> enqueueMessage (JText :: _ ('JERROR_ALERTNOAUTHOR'), 'error');
                        $ app-> setHeader ('status', 403, true);
                        return;                        
                }

For this

                // Check the view access to the article (the model has already computed the values).
                if ($item->params->get('access-view') == false && ($item->params->get('show_noauth', '0') == '0'))
                {
                        header('Location:https://www.yourwebpage/withLoginandCustomMessage.php');
                 die();
                }

This will only be shown to users trying to view articles that require registration or with other ACLs.

I am aware that we should not edit the files since in a Joomla update, these changes could be lost, but it was the only solution I found (neither modules or plugins covered this problem and apparently it is something that is brought from joomla 1.5).

I have been continuing to try to find a logical answer to this issue, continuing to search other threads to gleam a small particle of light that might realise into a solution. But I really am getting nowhere. I was hoping to take the test website to live very shortly, but I am not convinced this is such a good idea if there is no FTP layer, media management, or global configuration ability on the back end.

@Prax — I am not sure how you flag an issue up to the core team? I would have presumed that by a thread being posted here, and over the period of a week or so a considerable number of users flag up the same issue this would prompt a member of the core team to help, advise, guide, notify of known issues etc. Perhaps I am wrong. Perhaps they are overwhelmed right now.

I will continue on my path of researching any possible answers, but as a Joomla coding novice, I am not holding out much hope. What is quite frustrating is that it probably can be solved very simply! Hey-ho!

???

EDIT TO ABOVE THREAD:
I went and had a scrummage around in the Joomla! 1.5 bug tracker(found at joomlacode.org), as I guessed it was likely that other people had had this issue, and to see how the issue was developing. Here is a solution that was suggested there — add the following code to your .htaccess file, I added it at the bottom and included a little text to explain what it is doing, so it can be easily removed if there is an issue with it:

########## Attempt to solve ‘Global Configuration’ save issue, FTP layer issue, Media Upload issue
SecFilterEngine Off
SecFilterScanPOST Off
########## End — Attempt to solve ‘Global Configuration’ save issue, FTP layer issue, Media Upload issue

Now I will say that this solved not only the issue that I had with the ability to save global configuration backend, but also to access the new J!1.5 FTP layer which I so desperately wanted, and hence solved the issue with uploading media to media manager back end.

The FTP Backend settings I found to work were as following:
Enable FTP: Yes
FTP Host: ftp.yoursubdomain.yourdomain.com
FTP Port: 21
FTP Username: [email protected] (having set up an FTP user specifically for the domain or subdomain)
FTP Password: ********** (using the password relevant to the FTP user above)
FTP Root: /

What does concern me somewhat is — does setting SecFilterEngine and SecFilterScanPOST to OFF leave vulnerabilities to the website/Joomla install/host? I would really like to hear from a Joomla core member to validate if this is the fact. Is there anybody out there that could advise? If we could get guidance from higher powers (ie people who know what they are doing!), and therefore feel more comfortable testing the principle, this could possibly be a way forward?

Cheers
FiveD

Понравилась статья? Поделить с друзьями:
  • Джули шаверни и ее двойная ошибка
  • Джон дир ошибка 9417
  • Джифорс экспириенс произошла ошибка перезапустите игру
  • Джон дир 9430 коды ошибок
  • Джон дир 8420 коды ошибок