http transport should tell that authentication is required instead of failing with an HTTPError exception

Bug #42383 reported by Guilherme Salgado
4
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
Medium
Vincent Ladeuil

Bug Description

If you try to branch/pull from a location that requires authentication you'll get a traceback like the following.

  File "/srv/sm-ng/production/launchpad/cronscripts/../lib/bzrlib/transport/http.py", line+88, in get_url
    response = opener.open(request)
  File "/usr/lib/python2.4/urllib2.py", line 364, in open
    response = meth(req, response)
  File "/usr/lib/python2.4/urllib2.py", line 471, in http_response
    response = self.parent.error(
  File "/usr/lib/python2.4/urllib2.py", line 402, in error
    return self._call_chain(*args)
  File "/usr/lib/python2.4/urllib2.py", line 337, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.4/urllib2.py", line 480, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 401: Authorization Required

Related branches

Revision history for this message
Vincent Ladeuil (vila) wrote :

In bzr 0.11.0dev0 you get another traceback:
bzr: ERROR: exceptions.ValueError: unsupported format character '@' (0x40) at index 12

Traceback (most recent call last):
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/commands.py", line 611, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/commands.py", line 573, in run_bzr
    ret = run(*run_argv)
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/commands.py", line 282, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/builtins.py", line 660, in run
    br_from = Branch.open(from_location)
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/branch.py", line 113, in open
    control = bzrdir.BzrDir.open(base, _unsupported)
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/bzrdir.py", line 470, in open
    format = BzrDirFormat.find_format(t)
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/bzrdir.py", line 995, in find_format
    return format.probe_transport(transport)
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/bzrdir.py", line 1005, in probe_transport
    format_string = transport.get(".bzr/branch-format").read()
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/transport/http/__init__.py", line 226, in get
    code, response_file = self._get(relpath, None)
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/transport/http/_urllib.py", line 61, in _get
    tail_amount=tail_amount)
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/transport/http/_urllib.py", line 85, in _get_url_impl
    url = extract_auth(url, manager)
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/transport/http/__init__.py", line 72, in extract_auth
    user=username, host=host)
  File "/Volumes/unix/vila/src/bzr.dev/bzrlib/ui/text.py", line 76, in get_password
    prompt = (prompt % kwargs).encode(sys.stdout.encoding, 'replace')
ValueError: unsupported format character '@' (0x40) at index 12

bzr 0.11.0dev0 on python 2.4.2.final.0 (darwin)
arguments: ['/Volumes/home/vila/bin/bzr', 'branch', 'http+urllib://<user>@<host>/pub/web.dav/', 'webdav-local']

with the attached patch you get prompted for the password at each connection which becomes rapidly boring, but that's another story.

Changed in bzr:
status: Unconfirmed → Confirmed
Revision history for this message
John A Meinel (jameinel) wrote :

So the password manager isn't managing things correctly?

Also, this could be tested by writing a custom UIFactory that doesn't actually prompt the user, but just does:
prompt % kwargs
and returns something.

If you do that, we can easily merge the fix.

Revision history for this message
Vincent Ladeuil (vila) wrote :

The password manager does its job, the problem is that a new password manager is created for each request in the actual _urllib implementation.
To correct that, we need to share the connection between the requests of one transport first.
Then we should share that password manager between the transports.
At that point the question becomes: do we *globally* share one password manager or do we wait for bzr to provide transports "cousins" at transport creation ?
I favor the former because things can become complicated when handling redirections (in the worst case, you can have a new password required at each redirection). One can even imagine that multiple passwords get required for different directories inside the same repository (multiplied by the redirections, I don't even want to calculate how many passords the user may have to type... Ok, that is a bit extreme and we may forbid it, but...)

Vincent Ladeuil (vila)
Changed in bzr:
assignee: nobody → v-ladeuil
Revision history for this message
Vincent Ladeuil (vila) wrote :

Commited in ~bzr/bzr/bzr.urllib.keepalive

Changed in bzr:
status: Confirmed → In Progress
status: In Progress → Confirmed
status: Confirmed → In Progress
Revision history for this message
John A Meinel (jameinel) wrote :

urllib.keepalive should land in 0.13

Changed in bzr:
status: In Progress → Fix Committed
Vincent Ladeuil (vila)
Changed in bzr:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.