aboutsummaryrefslogtreecommitdiff
path: root/files/ru/web/http/authentication
diff options
context:
space:
mode:
authorFlorian Merz <me@fiji-flo.de>2021-02-11 14:51:05 +0100
committerFlorian Merz <me@fiji-flo.de>2021-02-11 14:51:05 +0100
commitc058fa0fb22dc40ef0225b21a97578cddd0aaffa (patch)
treedf20f8b4c724b61cb9c34cdb450a7ac77d690bd0 /files/ru/web/http/authentication
parent8260a606c143e6b55a467edf017a56bdcd6cba7e (diff)
downloadtranslated-content-c058fa0fb22dc40ef0225b21a97578cddd0aaffa.tar.gz
translated-content-c058fa0fb22dc40ef0225b21a97578cddd0aaffa.tar.bz2
translated-content-c058fa0fb22dc40ef0225b21a97578cddd0aaffa.zip
unslug ru: move
Diffstat (limited to 'files/ru/web/http/authentication')
-rw-r--r--files/ru/web/http/authentication/index.html123
1 files changed, 123 insertions, 0 deletions
diff --git a/files/ru/web/http/authentication/index.html b/files/ru/web/http/authentication/index.html
new file mode 100644
index 0000000000..99228e7633
--- /dev/null
+++ b/files/ru/web/http/authentication/index.html
@@ -0,0 +1,123 @@
+---
+title: HTTP авторизация
+slug: Web/HTTP/Авторизация
+tags:
+ - Авторизация
+ - Разграничение доступа
+ - Руководство
+translation_of: Web/HTTP/Authentication
+---
+<div>{{HTTPSidebar}}</div>
+
+<p class="summary">HTTP предоставляет набор инструментов для разграничения доступа к ресурсам и авторизацией. Самой распространенной схемой HTTP авторизации является "Basic" (базовая) авторизация. Данное руководство описывает основные возможности HTTP авторизации и показывает способы ограничения доступа к вашему серверу с ее использованием.</p>
+
+<h2 id="Общий_механизм_HTTP_авторизации">Общий механизм HTTP авторизации</h2>
+
+<p>{{RFC("7235")}} определяет средства HTTP авторизации, которые может использовать сервер для {{glossary("запроса")}} у клиента аутентификационной информации. Сценарий запрос-ответ подразумевает, что вначале сервер отвечает клиенту со статусом {{HTTPStatus("401")}} (Unauthorized) и предоставляет информацию о порядке авторизации через заголовок {{HTTPHeader("WWW-Authenticate")}}, содержащий хотя бы один метод авторизации. Клиент, который хочет авторизоваться, может сделать это, включив в следующий запрос заголовок {{HTTPHeader("Authorization")}} с требуемыми данными. Обычно, клиент отображает запрос пароля пользователю, и после получения ответа отправляет запрос с пользовательскими данными в заголовке <code>Authorization</code>.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/14689/HTTPAuth.png" style="height: 335px; width: 710px;"></p>
+
+<p>В случае базовой авторизации как на иллюстрации выше, обмен <strong>должен</strong> вестись через HTTPS (TLS) соединение, чтобы обеспечить защищённость.</p>
+
+<h3 id="Прокси-авторизация">Прокси-авторизация</h3>
+
+<p>Этот же механизм запроса и ответа может быть использован для <em>прокси-авторизации</em>. В таком случае ответ посылает промежуточный прокси-сервер, который требует авторизации. Поскольку обе формы авторизации могут использоваться одновременно, для них используются разные заголовки и коды статуса ответа. В случае с <em>прокси</em>, статус-код запроса {{HTTPStatus("407")}} (Proxy Authentication Required) и заголовок {{HTTPHeader("Proxy-Authenticate")}}, который содержит хотя бы один запрос, относящийся к прокси-авторизации, а для передачи авторизационных данных прокси-серверу используется заголовок {{HTTPHeader("Proxy-Authorization")}}.</p>
+
+<h3 id="Доступ_запрещен">Доступ запрещен</h3>
+
+<p>Если (прокси) сервер получает корректные учетные данные, но они не подходят для доступа к данному ресурсу, сервер должен отправить ответ со статус кодом {{HTTPStatus("403")}} <code>Forbidden</code>. В отличии от статус кода {{HTTPStatus("401")}} <code>Unauthorized</code> или {{HTTPStatus("407")}} <code>Proxy Authentication Required</code>, аутентификация для этого пользователя не возможна.</p>
+
+<h3 id="Аутентификация_с_помощью_изображений">Аутентификация с помощью изображений</h3>
+
+<p>Аутентификация с помощью изображений, загружаемых из разных источников, была до недавнего времени потенциальной дырой в безопасности. Начиная с <a href="https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/59">Firefox 59</a>, изображения, загружаемые из разных источников в текущий документ, больше не запускают диалог HTTP-аутентификации, предотвращая тем самым кражу пользовательских данных (если нарушители смогли встроить это изображение в страницу).</p>
+
+<h3 id="Кодировка_символов_HTTP_аутентификации">Кодировка символов HTTP аутентификации</h3>
+
+<p>Браузеры используют кодировку <code>utf-8</code> для имени пользователя и пароля. Firefox использовал <code>ISO-8859-1</code>, но она была заменена <code>utf-8</code> с целью уравнения с другими браузерами, а также чтобы избежать потенциальных проблем (таких как {{bug(1419658)}}).</p>
+
+<h3 id="WWW-Authenticate_and_Proxy-Authenticate_headers"><code>WWW-Authenticate</code> and <code>Proxy-Authenticate</code> headers</h3>
+
+<p>{{HTTPHeader("WWW-Authenticate")}} и {{HTTPHeader("Proxy-Authenticate")}} заголовки ответа которые определяют методы, что следует использовать для получения доступа к ресурсу. Они должны указывать, какую схему аутентификации использовать, чтобы клиент, желающий авторизоваться, знал, какие данные предоставить. Синтаксис для этих заголовков следующий:</p>
+
+<pre class="syntaxbox">WWW-Authenticate: &lt;type&gt; realm=&lt;realm&gt;
+Proxy-Authenticate: &lt;type&gt; realm=&lt;realm&gt;
+</pre>
+
+<p>Here, <code>&lt;type&gt;</code> is the authentication scheme ("Basic" is the most common scheme and <a href="/en-US/docs/Web/HTTP/Authentication#Basic_authentication_scheme">introduced below</a>). The <em>realm</em> is used to describe the protected area or to indicate the scope of protection. This could be a message like "Access to the staging site" or similar, so that the user knows to which space they are trying to get access to.</p>
+
+<h3 id="Authorization_and_Proxy-Authorization_headers"><code>Authorization</code> and <code>Proxy-Authorization</code> headers</h3>
+
+<p>The {{HTTPHeader("Authorization")}} and {{HTTPHeader("Proxy-Authorization")}} request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the type is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.</p>
+
+<pre class="syntaxbox">Authorization: &lt;type&gt; &lt;credentials&gt;
+Proxy-Authorization: &lt;type&gt; &lt;credentials&gt;
+</pre>
+
+<h3 id="Authentication_schemes">Authentication schemes</h3>
+
+<p>The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.</p>
+
+<p>The most common authentication scheme is the "Basic" authentication scheme which is introduced in more details below. IANA maintains a <a class="external external-icon" href="http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">list of authentication schemes</a>, but there are other schemes offered by host services, such as Amazon AWS. Common authentication schemes include:</p>
+
+<ul>
+ <li><strong>Basic</strong> (see {{rfc(7617)}}, base64-encoded credentials. See below for more information.),</li>
+ <li><strong>Bearer</strong> (see {{rfc(6750)}}, bearer tokens to access OAuth 2.0-protected resources),</li>
+ <li><strong>Digest</strong> (see {{rfc(7616)}}, only md5 hashing is supported in Firefox, see {{bug(472823)}} for SHA encryption support),</li>
+ <li><strong>HOBA</strong> (see {{rfc(7486)}} (draft), <strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication, digital-signature-based),</li>
+ <li><strong>Mutual</strong> (see <a href="https://tools.ietf.org/html/draft-ietf-httpauth-mutual-11">draft-ietf-httpauth-mutual</a>),</li>
+ <li>
+ <p><strong>AWS4-HMAC-SHA256</strong> (see <a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">AWS docs</a>).</p>
+ </li>
+</ul>
+
+<h2 id="Basic_authentication_scheme">Basic authentication scheme</h2>
+
+<p>The "Basic" HTTP authentication scheme is defined in {{rfc(7617)}}, which transmits credentials as user ID/password pairs, encoded using base64.</p>
+
+<h3 id="Security_of_basic_authentication">Security of basic authentication</h3>
+
+<p>As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.</p>
+
+<h3 id="Restricting_access_with_Apache_and_basic_authentication">Restricting access with Apache and basic authentication</h3>
+
+<p>To password-protect a directory on an Apache server, you will need a <code>.htaccess</code> and a <code>.htpasswd</code> file.</p>
+
+<p>The <code>.htaccess</code> file typically looks like this:</p>
+
+<pre>AuthType Basic
+AuthName "Access to the staging site"
+AuthUserFile /path/to/.htpasswd
+Require valid-user</pre>
+
+<p>The <code>.htaccess</code> file references a <code>.htpasswd</code> file in which each line contains of a username and a password separated by a colon (":"). You can not see the actual passwords as they are <a href="https://httpd.apache.org/docs/2.4/misc/password_encryptions.html">encrypted</a> (md5 in this case). Note that you can name your <code>.htpasswd</code> file differently if you like, but keep in mind this file shouldn't be accessible to anyone. (Apache is usually configured to prevent access to <code>.ht*</code> files).</p>
+
+<pre>aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
+user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
+</pre>
+
+<h3 id="Restricting_access_with_nginx_and_basic_authentication">Restricting access with nginx and basic authentication</h3>
+
+<p>For nginx, you will need to specify a location that you are going to protect and the <code>auth_basic</code> directive that provides the name to the password-protected area. The <code>auth_basic_user_file</code> directive then points to a .htpasswd file containing the encrypted user credentials, just like in the Apache example above.</p>
+
+<pre>location /status {
+ auth_basic "Access to the staging site";
+ auth_basic_user_file /etc/apache2/.htpasswd;
+}</pre>
+
+<h3 id="Access_using_credentials_in_the_URL">Access using credentials in the URL</h3>
+
+<p>Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:</p>
+
+<pre class="example-bad">https://username:password@www.example.com/</pre>
+
+<p><strong>The use of these URLs is deprecated</strong>. In Chrome, the <code>username:password@</code> part in URLs is even<a href="https://bugs.chromium.org/p/chromium/issues/detail?id=82250#c7"> stripped out</a> for security reasons. In Firefox, it is checked if the site actually requires authentication and if not, Firefox will warn the user with a prompt "You are about to log in to the site “www.example.com” with the username “username”, but the website does not require authentication. This may be an attempt to trick you.".</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li>{{HTTPHeader("WWW-Authenticate")}}</li>
+ <li>{{HTTPHeader("Authorization")}}</li>
+ <li>{{HTTPHeader("Proxy-Authorization")}}</li>
+ <li>{{HTTPHeader("Proxy-Authenticate")}}</li>
+ <li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li>
+</ul>