mirror of
https://github.com/postgres/postgres.git
synced 2025-07-31 22:04:40 +03:00
Spell and markup checking
This commit is contained in:
@ -1,4 +1,4 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.140 2010/07/29 19:34:40 petere Exp $ -->
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.141 2010/08/17 04:37:20 petere Exp $ -->
|
||||
|
||||
<chapter id="client-authentication">
|
||||
<title>Client Authentication</title>
|
||||
@ -80,7 +80,7 @@
|
||||
A record is made
|
||||
up of a number of fields which are separated by spaces and/or tabs.
|
||||
Fields can contain white space if the field value is quoted.
|
||||
Quoting one of the keywords in a database or username field (e.g.,
|
||||
Quoting one of the keywords in a database or user name field (e.g.,
|
||||
<literal>all</> or <literal>replication</>) makes the word lose its special
|
||||
character, and just match a database or user with that name.
|
||||
</para>
|
||||
@ -578,10 +578,10 @@ local db1,db2,@demodbs all md5
|
||||
</sect1>
|
||||
|
||||
<sect1 id="auth-username-maps">
|
||||
<title>Username maps</title>
|
||||
<title>User name maps</title>
|
||||
|
||||
<indexterm zone="auth-username-maps">
|
||||
<primary>Username maps</primary>
|
||||
<primary>User name maps</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
@ -589,10 +589,10 @@ local db1,db2,@demodbs all md5
|
||||
the name of the operating system user that initiated the connection
|
||||
might not be the same as the database user he needs to connect as.
|
||||
In this case, a user name map can be applied to map the operating system
|
||||
username to a database user. To use username mapping, specify
|
||||
user name to a database user. To use user name mapping, specify
|
||||
<literal>map</literal>=<replaceable>map-name</replaceable>
|
||||
in the options field in <filename>pg_hba.conf</filename>. This option is
|
||||
supported for all authentication methods that receive external usernames.
|
||||
supported for all authentication methods that receive external user names.
|
||||
Since different mappings might be needed for different connections,
|
||||
the name of the map to be used is specified in the
|
||||
<replaceable>map-name</replaceable> parameter in <filename>pg_hba.conf</filename>
|
||||
@ -600,7 +600,7 @@ local db1,db2,@demodbs all md5
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Username maps are defined in the ident map file, which by default is named
|
||||
User name maps are defined in the ident map file, which by default is named
|
||||
<filename>pg_ident.conf</><indexterm><primary>pg_ident.conf</primary></indexterm>
|
||||
and is stored in the
|
||||
cluster's data directory. (It is possible to place the map file
|
||||
@ -636,13 +636,13 @@ local db1,db2,@demodbs all md5
|
||||
expression can include a single capture, or parenthesized subexpression,
|
||||
which can then be referenced in the <replaceable>database-username</>
|
||||
field as <literal>\1</> (backslash-one). This allows the mapping of
|
||||
multiple usernames in a single line, which is particularly useful for
|
||||
multiple user names in a single line, which is particularly useful for
|
||||
simple syntax substitutions. For example, these entries
|
||||
<programlisting>
|
||||
mymap /^(.*)@mydomain\.com$ \1
|
||||
mymap /^(.*)@otherdomain\.com$ guest
|
||||
</programlisting>
|
||||
will remove the domain part for users with system usernames that end with
|
||||
will remove the domain part for users with system user names that end with
|
||||
<literal>@mydomain.com</>, and allow any user whose system name ends with
|
||||
<literal>@otherdomain.com</> to log in as <literal>guest</>.
|
||||
</para>
|
||||
@ -652,7 +652,7 @@ mymap /^(.*)@otherdomain\.com$ guest
|
||||
Keep in mind that by default, a regular expression can match just part of
|
||||
a string. It's usually wise to use <literal>^</> and <literal>$</>, as
|
||||
shown in the above example, to force the match to be to the entire
|
||||
system username.
|
||||
system user name.
|
||||
</para>
|
||||
</tip>
|
||||
|
||||
@ -835,7 +835,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
If set to <literal>1</>, the realm name from the authenticated user
|
||||
principal is included in the system user name that's passed through
|
||||
username mapping (<xref linkend="auth-username-maps">). This is
|
||||
user name mapping (<xref linkend="auth-username-maps">). This is
|
||||
useful for handling users from multiple realms.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -845,10 +845,10 @@ omicron bryanh guest1
|
||||
<term><literal>map</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows for mapping between system and database usernames. See
|
||||
Allows for mapping between system and database user names. See
|
||||
<xref linkend="auth-username-maps"> for details. For a Kerberos
|
||||
principal <literal>username/hostbased@EXAMPLE.COM</literal>, the
|
||||
username used for mapping is <literal>username/hostbased</literal>
|
||||
user name used for mapping is <literal>username/hostbased</literal>
|
||||
if <literal>include_realm</literal> is disabled, and
|
||||
<literal>username/hostbased@EXAMPLE.COM</literal> if
|
||||
<literal>include_realm</literal> is enabled.
|
||||
@ -862,7 +862,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
Sets the realm to match user principal names against. If this parameter
|
||||
is set, only users of that realm will be accepted. If it is not set,
|
||||
users of any realm can connect, subject to whatever username mapping
|
||||
users of any realm can connect, subject to whatever user name mapping
|
||||
is done.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -906,7 +906,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
If set to <literal>1</>, the realm name from the authenticated user
|
||||
principal is included in the system user name that's passed through
|
||||
username mapping (<xref linkend="auth-username-maps">). This is
|
||||
user name mapping (<xref linkend="auth-username-maps">). This is
|
||||
useful for handling users from multiple realms.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -916,7 +916,7 @@ omicron bryanh guest1
|
||||
<term><literal>map</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows for mapping between system and database usernames. See
|
||||
Allows for mapping between system and database user names. See
|
||||
<xref linkend="auth-username-maps"> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -928,7 +928,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
Sets the realm to match user principal names against. If this parameter
|
||||
is set, only users of that realm will be accepted. If it is not set,
|
||||
users of any realm can connect, subject to whatever username mapping
|
||||
users of any realm can connect, subject to whatever user name mapping
|
||||
is done.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1006,13 +1006,13 @@ omicron bryanh guest1
|
||||
<para>
|
||||
Client principals must have their <productname>PostgreSQL</> database user
|
||||
name as their first component, for example
|
||||
<literal>pgusername@realm</>. Alternatively, you can use a username
|
||||
<literal>pgusername@realm</>. Alternatively, you can use a user name
|
||||
mapping to map from the first component of the principal name to the
|
||||
database user name. By default, the realm of the client is
|
||||
not checked by <productname>PostgreSQL</>. If you have cross-realm
|
||||
authentication enabled and need to verify the realm, use the
|
||||
<literal>krb_realm</> parameter, or enable <literal>include_realm</>
|
||||
and use username mapping to check the realm.
|
||||
and use user name mapping to check the realm.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1041,7 +1041,7 @@ omicron bryanh guest1
|
||||
principal matching the requested database user name. For example, for
|
||||
database user name <literal>fred</>, principal
|
||||
<literal>fred@EXAMPLE.COM</> would be able to connect. To also allow
|
||||
principal <literal>fred/users.example.com@EXAMPLE.COM</>, use a username
|
||||
principal <literal>fred/users.example.com@EXAMPLE.COM</>, use a user name
|
||||
map, as described in <xref linkend="auth-username-maps">.
|
||||
</para>
|
||||
|
||||
@ -1063,7 +1063,7 @@ omicron bryanh guest1
|
||||
<term><literal>map</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows for mapping between system and database usernames. See
|
||||
Allows for mapping between system and database user names. See
|
||||
<xref linkend="auth-username-maps"> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1075,7 +1075,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
If set to <literal>1</>, the realm name from the authenticated user
|
||||
principal is included in the system user name that's passed through
|
||||
username mapping (<xref linkend="auth-username-maps">). This is
|
||||
user name mapping (<xref linkend="auth-username-maps">). This is
|
||||
useful for handling users from multiple realms.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1087,7 +1087,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
Sets the realm to match user principal names against. If this parameter
|
||||
is set, only users of that realm will be accepted. If it is not set,
|
||||
users of any realm can connect, subject to whatever username mapping
|
||||
users of any realm can connect, subject to whatever user name mapping
|
||||
is done.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1119,7 +1119,7 @@ omicron bryanh guest1
|
||||
<para>
|
||||
The ident authentication method works by obtaining the client's
|
||||
operating system user name and using it as the allowed database user
|
||||
name (with an optional username mapping).
|
||||
name (with an optional user name mapping).
|
||||
The determination of the client's
|
||||
user name is the security-critical point, and it works differently
|
||||
depending on the connection type, as described below.
|
||||
@ -1132,7 +1132,7 @@ omicron bryanh guest1
|
||||
<term><literal>map</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows for mapping between system and database usernames. See
|
||||
Allows for mapping between system and database user names. See
|
||||
<xref linkend="auth-username-maps"> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1245,7 +1245,7 @@ omicron bryanh guest1
|
||||
|
||||
<para>
|
||||
In the second mode, the server first binds to the LDAP directory with
|
||||
a fixed username and password, specified with <replaceable>ldapbinduser</>
|
||||
a fixed user name and password, specified with <replaceable>ldapbinduser</>
|
||||
and <replaceable>ldapbinddn</>, and performs a search for the user trying
|
||||
to log in to the database. If no user and password is configured, an
|
||||
anonymous bind will be attempted to the directory. The search will be
|
||||
@ -1295,7 +1295,7 @@ omicron bryanh guest1
|
||||
<term><literal>ldapprefix</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
String to prepend to the username when forming the DN to bind as,
|
||||
String to prepend to the user name when forming the DN to bind as,
|
||||
when doing simple bind authentication.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1304,7 +1304,7 @@ omicron bryanh guest1
|
||||
<term><literal>ldapsuffix</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
String to append to the username when forming the DN to bind as,
|
||||
String to append to the user name when forming the DN to bind as,
|
||||
when doing simple bind authentication.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1340,7 +1340,7 @@ omicron bryanh guest1
|
||||
<term><literal>ldapsearchattribute</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Attribute to match against the username in the search when doing
|
||||
Attribute to match against the user name in the search when doing
|
||||
search+bind authentication.
|
||||
</para>
|
||||
</listitem>
|
||||
@ -1464,9 +1464,9 @@ ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
|
||||
the client provide a valid certificate. No password prompt will be sent
|
||||
to the client. The <literal>cn</literal> (Common Name) attribute of the
|
||||
certificate
|
||||
will be compared to the requested database username, and if they match
|
||||
the login will be allowed. Username mapping can be used to allow
|
||||
<literal>cn</literal> to be different from the database username.
|
||||
will be compared to the requested database user name, and if they match
|
||||
the login will be allowed. User name mapping can be used to allow
|
||||
<literal>cn</literal> to be different from the database user name.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -1477,7 +1477,7 @@ ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
|
||||
<term><literal>map</literal></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Allows for mapping between system and database usernames. See
|
||||
Allows for mapping between system and database user names. See
|
||||
<xref linkend="auth-username-maps"> for details.
|
||||
</para>
|
||||
</listitem>
|
||||
|
Reference in New Issue
Block a user