1
Authentication Settings
2
=======================
8
Many different authentication policies can be described in the
9
``authentication.conf`` file but a particular user should need only a few
10
definitions to cover his needs without having to specify a user and a password
11
for every branch he uses.
13
The definitions found in this file are used to find the credentials to use for
14
a given url. The same credentials can generally be used for as many branches as
15
possible by grouping their declaration around the remote servers that need
16
them. It's even possible to declare credentials that will be used by different
19
The intent is to make this file as small as possible to minimize maintenance.
21
Once the relevant credentials are declared in this file you may use branch urls
22
without embedding passwords (security hazard) or even users (enabling sharing
23
of your urls with others).
27
bzr branch ftp://joe:secret@host.com/path/to/my/branch
31
bzr branch ftp://host.com/path/to/my/branch
33
provided you have created the following ``authentication.conf`` file::
42
Authentication definitions
43
--------------------------
45
There are two kinds of authentication used by the various schemes supported by
50
``FTP`` needs a (``user``, ``password``) to authenticate against a ``host``
51
``SFTP`` can use either a password or a host key to authenticate. However,
52
ssh agents are a better, more secure solution. So we have chosen to not provide
53
our own less secure method.
55
2. user, realm and password
57
``HTTP`` and ``HTTPS`` needs a (``user, realm, password``) to authenticate
58
against a host. But, by using ``.htaccess`` files, for example, it is possible
59
to define several (``user, realm, password``) for a given ``host``. So what is
60
really needed is (``user``, ``password``, ``host``, ``path``). The ``realm`` is
61
not taken into account in the defitions, but will displayed if bzr prompts you
64
``HTTP proxy`` can be handled as ``HTTP`` (or ``HTTPS``) by explicitely
65
specifying the appropriate port.
67
To take all schemes into account, the password will be deduced from a set of
68
authentication definitions (``scheme``, ``host``, ``port``, ``path``, ``user``,
71
* ``scheme``: can be empty (meaning the rest of the definition can be used
72
for any scheme), ``SFTP`` and ``bzr+ssh`` should not be used here, ``ssh``
73
should be used instead since this is the real scheme regarding
76
* ``host``: can be empty (to act as a default for any host),
78
* ``port`` can be empty (useful when an host provides several servers for the
79
same scheme), only numerical values are allowed, this should be used only
80
when the server uses a port different than the scheme standard port,
82
* ``path``: can be empty (FTP or SFTP will never user it),
84
* ``user``: can be empty (``bzr`` will defaults to python's
85
``getpass.get_user()``),
87
* ``password``: can be empty if you prefer to always be prompted for your
90
Multiple definitions can be provided and, for a given URL, bzr will select a
91
(``user`` [, ``password``]) based on the following rules :
93
1. the first match wins,
95
2. empty fields match everything,
97
3. ``scheme`` matches even if decorators are used in the requested URL,
99
4. ``host`` matches exactly or act as a domain if it starts with '.'
100
(``project.bzr.sf.net`` will match ``.bzr.sf.net`` but ``projectbzr.sf.net``
101
will not match ``bzr.sf.net``).
103
5. ``port`` matches if included in the requested URL (exact matches only)
105
6. ``path`` matches if included in the requested URL (and by rule #2 above,
106
empty paths will match any provided path).
113
The general rules for `configuration files`_ apply except for the variable
116
.. _configuration files: #configuration-settings
118
Each section describes an authentication definition.
120
The section name is an arbitrary string, only the ``DEFAULT`` value is reserved
121
and should appear as the *last* section.
123
Each section should define:
125
* ``user``: the login to be used,
127
Each section could define:
129
* ``host``: the remote server,
131
* ``port``: the port the server is listening,
133
* ``path``: the branch location,
135
* ``password``: the password.
142
Personal projects hosted outside
143
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
145
All connections are done with the same ``user`` (the remote one for which the
146
default bzr one is not appropriate) and the password is always prompted with
149
# Pet projects on hobby.net
163
# Our local user is barbaz, on all remote sites we're known as foobar
167
Source hosting provider
168
~~~~~~~~~~~~~~~~~~~~~~~
170
In the shp.net (fictious) domain, each project has its own site::
173
# we use sftp, but ssh is the scheme used for authentication
175
# The leading '.' ensures that 'shp.net' alone doesn't match
178
# bzr don't support supplying a password for sftp,
179
# consider using an ssh agent if you don't want to supply
180
# a password interactively. (pageant, ssh-agent, etc)
182
HTTPS, SFTP servers and their proxy
183
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
185
At company.com, the server hosting release and integration branches is behind a
186
proxy, and the two branches use different authentication policies::
195
# development branches on dev server
197
scheme=ssh # bzr+ssh and sftp are available here
199
path=/dev/integration
205
host=proxy.company.com
214
The following are not yet implemented but planned as parts of a work in
217
* add a ``password_encoding`` field allowing:
219
- storing the passwords in various obfuscating encodings (base64 for one),
221
- delegate password storage to plugins (.netrc for example).
223
* update the credentials when the user is prompted for user or password,
225
* add a ``verify_certificates`` field for ``HTTPS``.
227
The ``password_encoding`` and ``verify_certificates`` fields are recognized but
228
ignored in the actual implementation.
added
removed
bzrlib/help_topics/en/authentication.txt
