[nagging as lifeless and Larstiq told me to] get_password with or without a prompt to address bug 72792

[Martin Pool]

On 3/16/07, Vincent Ladeuil <v.ladeuil+lp at free.fr> wrote:
> >>>>> "john" == John Arbash Meinel <john at arbash-meinel.com> writes:
>
>     john> John Arbash Meinel has voted +1.
>     john> Status is now: Semi-approved
>     john> Comment:
>     john> I happy enough with this.
>
>     john> I do thing we want to end up with a
>
>     john> get_password(user='x', host='y') and get rid of the 'prompt=' variable.
>
> 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.

I think we should handle both having the username in the url, but also
do the right thing if the server 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.

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

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

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

> 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.

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

-- 
Martin