[MERGE] Authentication Ring spec

[Martin Pool]

Mozilla remembers passwords (in 'signons2.txt') indexed by scheme,
hostname, port, realm.  The realm is only present for http or https
protocol-level authentication, not for passwords in a web form (which is
not relevant to us.)

Mozilla doesn't take into account having different credentials on the same
host when they are not distinguished by realms.  I think that's quite
reasonable for auto-remembered passwords -- it is a rare situation --
though in the proposed scheme you could configure for this.

They can also remember passwords for multiple usernames, which would be an
interesting extension.

I thought of another reason to make the section headers meaningful, not
arbitrary, which is that it makes automatic updating much more feasible.

So thinking about this, I think we should match by path if it's specified,
and by realm if it's specified.  An auto-remember feature will probably
want to record the scheme, hostname, port and realm (where applicable) but
not the path.  When people add entries by hand they will typically not add
the realm.

I think the section header really should be the key, as that makes it a
lot easier for us to automatically update them, and makes the expression
simpler when they're manually added.  It slightly complicates the parsing.
It makes it a bit harder to be sure of the syntax for when no scheme is
given, but it is rare to access a host which needs authentication by the
same password on two protocols, so I don't think we need to support that.

> +===================
> +
> +When accessing a remote branch (specified as an URL), it may occur that the
> +server request an authentication.

(French :-) 'requests authentication'

> +Also note that an optional ``self_certified`` field will be allowed to force
> +the connection to ``HTTPS`` hosts that provides a self certified certificate
> +(the default should be to refuse the connection and inform the user).

I think that name is not quite accurate; there are various ways the
certificate can be wrong.  Anyhow I'm not sure we can distinguish self
signed from "signed by a CA we don't know."  How about just
check_ssl_certificate=no.

> +The default content of the file will be::
> +
> +    [DEFAULT]
> +
> +This section could define:
> +
> +  * ``user``: default user to be used.
> +
> +  * ``password_encoding``: default password encoding.

We wouldn't want the user adding a password here that would be sent to all
random hosts they might connect to.  And I'm not so sure that a default
username which is not their local username is compelling.  So do we really
need this section?

> +The use cases described below use the file format defined above.
> +
> +  * all FTP connections to the foo.net domain are done with the same (``user``,
> +    ``password``)::
> +
> +        # Identity on foo.net
> +        [foo.net]
> +        scheme=ftp
> +        host=foo.net
> +        user=joe
> +        password=secret-pass

I think this should be

  [ftp://foo.net]
  user=joe
  password=secret-pass

> +  * Why can't bzr update the authentication file when it queried the user for a
> +    password ?
> +
> +    * a future version may address that but:
> +
> +      1. The user may want to decide which passwords are stored in the file and
> +         which aren't.
> +
> +      2. The user should decide if the passwords are encoded or not.

We'd want to prompt "do you want to remember this".  I think we can
reasonably always base64 them.

-- 
Martin