Apache ошибка 401

I currently have an application proxied through 2 separate web servers. One web server is running Apache 2.2 while the other web server is running Apache 2.4. While some of the configuration had to be changed to accommodate Apache 2.4, the configuration between these 2 web servers is essentially the same (we were upgrading web servers).

This application works fine when proxied through Apache 2.2, however when accessing the application through Apache 2.4 I run into an issue.

The application that I am accessing is constantly polling for data by sending out successive AJAX requests. After a certain amount of time/requests (does not seem to be consistent), the Apache 2.4 web server returns a 401 Unauthorized error causing the application to fail. Keep in mind that it works without issue for a period of time however the 401 error always presents itself within a couple of minutes.

When accessing the application via an internal IP or through the Apache 2.2 web server, I do not encounter this issue which leads me to believe Apache 2.4 is causing the issue. Something to do with the successive requests within a short period of time?

Is there a configuration setting that I need to include in Apache 2.4 in order for things to work properly? I am at a loss as to why the 401 error does not present itself initially (everything works fine initially), but does so after a short period of time.

Please let me know if you need any further information. I can provide any .conf files that are necessary. Your help is greatly appreciated.

EDIT: Apache 2.4 ‘apache2.conf’ file (comments removed):

Источник

Ошибка сервера 401: что это за ошибка и как ее исправить

Появление сообщения об ошибке 401 Unauthorized Error («отказ в доступе») при открытии страницы сайта означает неверную авторизацию или аутентификацию пользователя на стороне сервера при обращении к определенному url-адресу. Чаще всего она возникает при ошибочном вводе имени и/или пароля посетителем ресурса при входе в свой аккаунт. Другой причиной являются неправильные настройки, допущенные при администрировании web-ресурса. Данная ошибка отображается в браузере в виде отдельной страницы с соответствующим описанием. Некоторые разработчики интернет-ресурсов, в особенности крупных порталов, вводят собственную дополнительную кодировку данного сбоя:

• 401 Unauthorized;
• Authorization Required;
• HTTP Error 401 – Ошибка авторизации.

Попробуем разобраться с наиболее распространенными причинами возникновения данной ошибки кода HTTP-соединения и обсудим способы их решения.

Причины появления ошибки сервера 401 и способы ее устранения на стороне пользователя

При доступе к некоторым сайтам (или отдельным страницам этих сайтов), посетитель должен пройти определенные этапы получения прав:

1. Идентификация – получение вашей учетной записи («identity») по username/login или email.
2. Аутентификация («authentic») – проверка того, что вы знаете пароль от этой учетной записи.
3. Авторизация – проверка вашей роли (статуса) в системе и решение о предоставлении доступа к запрошенной странице или ресурсу на определенных условиях.

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

Наиболее распространенной причиной появления ошибки с кодом 401 для рядового пользователя является ввод неверных данных при посещении определенного ресурса. В этом и других случаях нужно попробовать сделать следующее:

1. Проверьте в адресной строке правильность написания URL. Особенно это касается перехода на подстраницы сайта, требующие авторизации. Введите правильный адрес. Если переход на страницу осуществлялся после входа в аккаунт, разлогинитесь, вернитесь на главную страницу и произведите повторный вход с правильными учетными данными.
2. При осуществлении входа с сохраненными данными пользователя и появлении ошибки сервера 401 проверьте их корректность в соответствующих настройках данного браузера. Возможно, авторизационные данные были вами изменены в другом браузере. Также можно очистить кэш, удалить cookies и повторить попытку входа. При удалении истории браузера или очистке кэша потребуется ручное введение логина и пароля для получения доступа. Если вы не помните пароль, пройдите процедуру восстановления, следуя инструкциям.
3. Если вы считаете, что вводите правильные регистрационные данные, но не можете получить доступ к сайту, обратитесь к администратору ресурса. В этом случае лучше всего сделать скриншот проблемной страницы.
4. Иногда блокировка происходит на стороне провайдера, что тоже приводит к отказу в доступе и появлению сообщения с кодировкой 401. Для проверки можно попробовать авторизоваться на том же ресурсе с альтернативного ip-адреса (например, используя VPN). При подтверждении блокировки трафика свяжитесь с провайдером и следуйте его инструкциям.

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

Иногда простая перезагрузка проблемной страницы, выход из текущей сессии или использование другого веб-браузера полностью решают проблему с 401 ошибкой авторизации.

Устранение ошибки 401 администратором веб-ресурса

Для владельцев сайтов, столкнувшихся с появлением ошибки отказа доступа 401, решить ее порою намного сложнее, чем обычному посетителю ресурса. Есть несколько рекомендаций, которые помогут в этом:

• Обращение в службу поддержки хостинга сайта. Как и в случае возникновения проблем с провайдером, лучше всего подробно описать последовательность действий, приведших к появлению ошибки 401, приложить скриншот.
• При отсутствии проблем на стороне хостинг-провайдера можно внести следующие изменения в настройки сайта с помощью строки Disallow:/адрес проблемной страницы. Запретить индексацию страницам с ошибкой в «rоbоts.txt», после чего добавить в файл «.htассеss» строку такого типа:

Где в поле /oldpage.html прописывается адрес проблемной страницы, а в http://site.com/newpage.html адрес страницы авторизации.

Таким образом вы перенаправите пользователей со всех страниц, которые выдают ошибку 401, на страницу начальной авторизации.

• Если после выполнения предыдущих рекомендаций пользователи при попытках авторизации все равно видят ошибку 401, то найдите на сервере файл «php.ini» и увеличьте время жизни сессии, изменив значения следующих параметров: «session.gc_maxlifetime» и «session.cookie_lifetime» на 1440 и 0 соответственно.
• Разработчики веб-ресурсов могут использовать более сложные методы авторизации и аутентификации доступа для создания дополнительной защиты по протоколу HTTP. Если устранить сбой простыми методами администрирования не удается, следует обратиться к специалистам, создававшим сайт, для внесения соответствующих изменений в код.

Хотя ошибка 401 и является проблемой на стороне клиента, ошибка пользователя на стороне сервера может привести к ложному требованию входа в систему. К примеру, сетевой администратор разрешит аутентификацию входа в систему всем пользователям, даже если это не требуется. В таком случае сообщение о несанкционированном доступе будет отображаться для всех, кто посещает сайт. Баг устраняется внесением соответствующих изменений в настройки.

Дополнительная информация об ошибке с кодом 401

Веб-серверы под управлением Microsoft IIS могут предоставить дополнительные данные об ошибке 401 Unauthorized в виде второго ряда цифр:

• 401, 1 – войти не удалось;
• 401, 2 – ошибка входа в систему из-за конфигурации сервера;
• 401, 3 – несанкционированный доступ из-за ACL на ресурс;
• 401, 501 – доступ запрещен: слишком много запросов с одного и того же клиентского IP; ограничение динамического IP-адреса – достигнут предел одновременных запросов и т.д.

Более подробную информацию об ошибке сервера 401 при использовании обычной проверки подлинности для подключения к веб-узлу, который размещен в службе MS IIS, смотрите здесь.

Следующие сообщения также являются ошибками на стороне клиента и относятся к 401 ошибке:

Как видим, появление ошибки авторизации 401 Unauthorized не является критичным для рядового посетителя сайта и чаще всего устраняется самыми простыми способами. В более сложной ситуации оказываются администраторы и владельцы интернет-ресурсов, но и они в 100% случаев разберутся с данным багом путем изменения настроек или корректировки html-кода с привлечением разработчика сайта.

Источник

HTTP Status Codes and Htaccess ErrorDocuments

I was trying to find an official, authoritative list of HTTP Status Codes but I kept finding lists that weren’t authoritative or complete. So I searched and found my answer in the Apache HTTP Server source code. Once I had the exact HTTP Status Codes and resulting Error Documents sent by Apache, I researched deeper into HTTP Status Codes by reading as many related RFC’s as I could find, and several other software source codes were explored. This is the most authoritative list I know of, if you can do better leave a comment and I’ll update it. Another thing to keep in mind, the Status code number itself is what is used by software and hardware to make determinations, the phrase returned by the status code is for the human only and does not have any weight other than informing the user.. So «503 Service Unavailable», «503 Service Temporarily Unavailable», and «503 Get the heck outta here» are all completely valid.

Update March 9, 2009: A lot of sites on the web have updated their HTTP status code lists to include the HTTP Status codes listed on this page, including Wikipedia, IANA, W3C, and others, so rest assured this info is accurate and complete. If you’d like to see how to create custom error pages for all of these errors like mine /show-error-506 , then check out this detailed tutorial I just posted.

57 APACHE HTTP STATUS RESPONSE CODES

Once I compiled the list of Apache recognized HTTP Status Codes, I was dying to see them all in action (i.e. the corresponding ErrorDocument). At first I thought I would have to create a php or perl script emulating each of the 57 HTTP Status Codes, a tedious undertaking I wasn’t about to do. Instead I «asked Apache» by searching the Apache HTTP Documentation for ambiguity sending Status Codes and/or triggering ErrorDocuments with an Apache Directive.
While reading up on mod_alias and the Redirect directive I found:

Syntax: Redirect [status] URL-path URL The status argument can be used to return other HTTP status codes. Other status codes can be returned by giving the numeric status code as the value of status. If the status is between 300 and 399, the URL argument must be present, otherwise it must be omitted.

1xx Info / Informational

HTTP_INFO — Request received, continuing process. Indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line.

2xx Success / OK

HTTP_SUCCESS — The action was successfully received, understood, and accepted. Indicates that the client’s request was successfully received, understood, and accepted.

3xx Redirect

HTTP_REDIRECT — The client must take additional action to complete the request. Indicates that further action needs to be taken by the user-agent in order to fulfill the request. The action required may be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A user agent should not automatically redirect a request more than 5 times, since such redirections usually indicate an infinite loop.

4xx Client Error

HTTP_CLIENT_ERROR — The request contains bad syntax or cannot be fulfilled. Indicates case where client seems to have erred. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition.

5xx Server Error

HTTP_SERVER_ERROR — The server failed to fulfill an apparently valid request. Indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents should display any included entity to the user. These response codes are applicable to any request method.

Quick Start to triggering ErrorDocuments for each Status Code

Let start with a quick and easy example. Add the following Redirect rules to your htaccess file, then open your browser and goto each url like yoursite.com/e/400 . Don’t create an /e/ directory or any files.

Automate the ErrorDocument Triggering

The htaccess Redirects

When a Status code is encountered, Apache outputs the Header and the ErrorDocument for that error code. So you can view any Header and the default ErrorDocument, by causing that numerical error code, which is caused by the Status Code.

For instance, if you request a file that doesn’t exist, a 404 Not Found Header is issued and the corresponding ErrorDocument is served with the 404 Not Found Header.

PHP script that gets and outputs the Headers/Content

Now all I have to do is add 57 Redirect Directives to my htaccess, and then request each of them 1 at a time from my browser to see the result, and use a packet sniffing program like WireShark to see the Headers. Uh, scratch that, that would take way too long!

Instead I hacked up a simple php script using cURL to automate sending GET Requests to each of the 57 Redirect URL-paths. A side benefit of using the php script is that it performs all 57 Requests concurrently and saves each Requests returned headers and content to an output buffer. After all 57 have been queried, the output buffer is flushed to the browser.

Источник