get_password with or without a prompt to address bug 72792

Vincent Ladeuil v.ladeuil+lp at free.fr
Fri Mar 16 08:32:21 GMT 2007


>>>>> "Martin" == Martin Pool <mbp at sourcefrog.net> writes:

<snip/>


    >> I may have to rethink about how I wanted to address bug #72792.
    >> 
    >> The idea was that if the http server replies with a 401
    >> Unauthorized, bzr may request a username and a password.
    >> 
    >> Another approach may be to *require* the username in the url so
    >> that we don't need get_login anymore.

    Martin> I think we should handle both having the username in
    Martin> the url, but also do the right thing if the server
    Martin> wants authentication and no username is specified.

    >> This approach will be more in line with the other transports
    >> which do not (or cannot) handle changing the username.

    Martin> The interesting thing is that we do allow you to omit
    Martin> the username for sftp or bzr+ssh, and people commonly
    Martin> do.  In that case we assume that it's the same as
    Martin> your local account name (or set in ssh_config), which
    Martin> is reasonable for ssh but not so much for https.

Blink. Sure, I missed that, thanks for the heads-up.

    Martin> People commonly share sftp urls (eg for the
    Martin> sftp://bazaar.launchpad.net/~bzr shared branches),
    Martin> with the implicit understanding that people will use
    Martin> their own account.  It would be nice if that worked
    Martin> for http too.

    Martin> That said I think setting it in the url would be
    Martin> totally fine to start with.


Ok, I'll do that in two steps then:

- make it work for http[s] with user specified and an error
  message if authentication is required (or the password is wrong),

- allow transports to query username if needed (if I can find a
  way to identify specific connection errors requiring a login),

    >> So I'll go with:
    >> 
    >> get_password(prompt, scheme, host, user, realm=None)
    >> 
    >> with a default value of prompt:
    >> %(scheme)s %(user)s@%(host)s  %(realm)s password'
    >> 
    >> with realm='for realm (blabla)' or empty if no realm is
    >> required.

    Martin> In what cases would the caller want to override the prompt?

...

Doh !

1) I had just redefined the prompt in a form usable by all
   transports and I was not that proud of the realm trick.

2) GUIs have to override get_password (to redefine how the user
   type the passsword),

I can't find a good answer to your question, so I guess prompt
will disappear from the parameter list ;-)

Thanks for the clarifications,

       Vincent



More information about the bazaar mailing list