diff options
Diffstat (limited to 'files/pl/web/http/authentication/index.html')
| -rw-r--r-- | files/pl/web/http/authentication/index.html | 135 |
1 files changed, 0 insertions, 135 deletions
diff --git a/files/pl/web/http/authentication/index.html b/files/pl/web/http/authentication/index.html deleted file mode 100644 index d1a365fd50..0000000000 --- a/files/pl/web/http/authentication/index.html +++ /dev/null @@ -1,135 +0,0 @@ ---- -title: HTTP authentication -slug: Web/HTTP/Authentication -translation_of: Web/HTTP/Authentication ---- -<div><font><font>{{HTTPSidebar}}</font></font></div> - -<p class="summary"><span class="seoSummary"><font><font>Protokół HTTP zapewnia ogólną strukturę kontroli dostępu i uwierzytelniania. </font><font>Ta strona stanowi wprowadzenie do struktury HTTP służącej do uwierzytelniania i pokazuje, jak ograniczyć dostęp do serwera za pomocą schematu HTTP „Basic”.</font></font></span></p> - -<h2 id="Ogólna_struktura_uwierzytelniania_HTTP"><font><font>Ogólna struktura uwierzytelniania HTTP</font></font></h2> - -<p><font><font>{{RFC ("7235")}} definiuje strukturę uwierzytelniania HTTP, która może być używana przez serwer do {{glosariusza ("wyzwanie")}} żądania klienta, a przez klienta do dostarczania informacji uwierzytelniających.</font></font></p> - -<p><font><font>Wyzwanie i przepływ odpowiedzi działają w następujący sposób:</font></font></p> - -<ol> - <li><font><font>Serwer odpowiada klientowi statusem odpowiedzi {{HTTPStatus ("401")}} (Unauthorized) i dostarcza informacji na temat autoryzacji za pomocą nagłówka odpowiedzi {{HTTPHeader ("WWW-Authenticate")}} zawierającego co najmniej jeden wyzwanie.</font></font></li> - <li>A client that wants to authenticate itself with the server can then do so by including an {{HTTPHeader("Authorization")}} request header with the credentials.</li> - <li>Usually a client will present a password prompt to the user and will then issue the request including the correct <code>Authorization</code> header.</li> -</ol> - -<p><img alt="A sequence diagram illustrating HTTP messages between a client and a server lifeline." src="https://mdn.mozillademos.org/files/14689/HTTPAuth.png" style="height: 335px; width: 710px;" title="Diagram sekwencji uwierzytelniania HTTP klient-serwer"></p> - -<p>In the case of a "Basic" authentication like shown in the figure, the exchange <strong>must</strong> happen over an HTTPS (TLS) connection to be secure.</p> - -<h3 id="Proxy_authentication">Proxy authentication</h3> - -<p>The same challenge and response mechanism can be used for <em>proxy authentication</em>. As both resource authentication and proxy authentication can coexist, a different set of headers and status codes is needed. In the case of proxies, the challenging status code is {{HTTPStatus("407")}} (Proxy Authentication Required), the {{HTTPHeader("Proxy-Authenticate")}} response header contains at least one challenge applicable to the proxy, and the {{HTTPHeader("Proxy-Authorization")}} request header is used for providing the credentials to the proxy server.</p> - -<h3 id="Access_forbidden">Access forbidden</h3> - -<p>If a (proxy) server receives valid credentials that are inadequate to access a given resource, the server should respond with the {{HTTPStatus("403")}} <code>Forbidden</code> status code. Unlike {{HTTPStatus("401")}} <code>Unauthorized</code> or {{HTTPStatus("407")}} <code>Proxy Authentication Required</code>, authentication is impossible for this user.</p> - -<h3 id="Authentication_of_cross-origin_images">Authentication of cross-origin images</h3> - -<p>A potential security hole recently been fixed by browsers is authentication of cross-site images. From <a href="/en-US/docs/Mozilla/Firefox/Releases/59">Firefox 59</a> onwards, image resources loaded from different origins to the current document are no longer able to trigger HTTP authentication dialogs ({{bug(1423146)}}), preventing user credentials being stolen if attackers were able to embed an arbitrary image into a third-party page.</p> - -<h3 id="Character_encoding_of_HTTP_authentication">Character encoding of HTTP authentication</h3> - -<p>Browsers use <code>utf-8</code> encoding for usernames and passwords.</p> - -<p>Firefox once used <code>ISO-8859-1</code>, but changed to <code>utf-8</code> for parity with other browsers and to avoid potential problems as described in {{bug(1419658)}}.</p> - -<h3 id="WWW-Authenticate_and_Proxy-Authenticate_headers">WWW-Authenticate and Proxy-Authenticate headers</h3> - -<p>The {{HTTPHeader("WWW-Authenticate")}} and {{HTTPHeader("Proxy-Authenticate")}} response headers define the authentication method that should be used to gain access to a resource. They must specify which authentication scheme is used, so that the client that wishes to authorize knows how to provide the credentials.</p> - -<p>The syntax for these headers is the following:</p> - -<pre class="syntaxbox notranslate">WWW-Authenticate: <type> realm=<realm> -Proxy-Authenticate: <type> realm=<realm> -</pre> - -<p>Here, <code><type></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">Authorization and Proxy-Authorization 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 <code><type></code> is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.</p> - -<pre class="syntaxbox notranslate">Authorization: <type> <credentials> -Proxy-Authorization: <type> <credentials> -</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 detail below. IANA maintains a <a class="external external-icon" href="https://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> - -<dl> - <dt><strong>Basic</strong></dt> - <dd>See {{rfc(7617)}}, base64-encoded credentials. More information below.</dd> - <dt><strong>Bearer</strong></dt> - <dd>See {{rfc(6750)}}, bearer tokens to access OAuth 2.0-protected resources</dd> - <dt><strong>Digest</strong></dt> - <dd>See {{rfc(7616)}}, only md5 hashing is supported in Firefox, see {{bug(472823)}} for SHA encryption support</dd> - <dt><strong>HOBA</strong></dt> - <dd>See {{rfc(7486)}}, Section 3, <strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication, digital-signature-based</dd> - <dt><strong>Mutual</strong></dt> - <dd>See {{rfc(8120)}}</dd> - <dt><strong>AWS4-HMAC-SHA256</strong></dt> - <dd>See <a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">AWS docs</a></dd> -</dl> - -<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 <strong>is not secure</strong>. HTTPS/TLS should be used 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 class="notranslate">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 consists of a username and a password separated by a colon (<code>:</code>). You cannot see the actual passwords as they are <a href="https://httpd.apache.org/docs/2.4/misc/password_encryptions.html">hashed</a> (using MD5-based hashing, 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 class="notranslate">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 <code>.htpasswd</code> file containing the encrypted user credentials, just like in the Apache example above.</p> - -<pre class="notranslate">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 notranslate">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><font><font>{{HTTPStatus ("401")}}, {{HTTPStatus ("403")}}, {{HTTPStatus ("407")}}</font></font></li> -</ul> |