[MERGE] authentication ring specification
v.ladeuil+lp at free.fr
Tue Jul 24 22:36:56 BST 2007
>>>>> "aaron" == Aaron Bentley <aaron.bentley at utoronto.ca> writes:
aaron> Vincent Ladeuil wrote:
>> +.. [#ignored_realm] The true purpose of realms is to
>> +allow the same credentials to be reused for disjoint
>> +hierarchies. Ignoring them in this specifications aims to
>> +simplify the user experience.
aaron> I don't really see a simplification in ignoring realm.
aaron> I think it would be a much better identifier than
Look at it from the opposite point of view then: specifying realm
will complicate the user job for no added value. My point in
ignoring realm is that in nearly all the cases one user will have
access to one or several trees *all under the same realm*.
The only case I can imagine is a tree inside which several realms
are defined for several set of directories (gee, even trying to
express it...). A complicated setup far easier to declare as
I'm sure realms have value... but not for organizing a source
tree or a source tree collection.
Realm is really any string the server admin choose, a
prompt. It's specific to http. It's even possible, via the
.htaccess files to use the same realm even if the credentials are
I really think path is a far better identifier, it's common to
all schemes, it's really what the user see, I'm pretty sure that
only a few people can spot the realm when prompt for a password
from a browser and they don't care ! All they have to know is
>> + * while ``locations.conf`` is intended to describe *local* branches,
>> + ``authentication.conf`` is intended to describe *remote* branches or
>> + servers.
aaron> locations.conf is intended to describe both local and
aaron> remote branches. In particular, it provides a way to
aaron> override the branch.conf settings in a remote branch
aaron> that you do not have write access to.
Ok, that was poorly expressed then, what I wanted to say was that
locations.conf describes properties organized by local branches
(and indeed can specify settings for remote branches) whereas
authentication.conf describes properties organized by remote
branches (or even remote servers).
>> + * What about using ``seahorse`` on Ubuntu or ``KeyChain Access`` on Mac OS X ?
>> + * ``svn`` use some native APIs to encode its cached
>> + credentials, that may provides examples on how this
>> + can be done for bzr, then these services could be
>> + used to encrypt the passwords and define a new
>> + ``password_encoding``.
aaron> It seems worth investigating the seahorse or KeyChain
aaron> Access APIs before finalizing this spec. Such
aaron> analysis would ensure that our spec is compatible with
aaron> them, and reading about their APIs could reveal issues
aaron> that we need to address.
Ok, I'll investigate them then,
More information about the bazaar