I noticed that the exception printed in the previous commit started on the same
line as the print for the `str(e)` case right before it. Since this also prints
the content of urllib2.URLError.read(), it seems better to remove any existing
newline and re-add it, than to just assume the `str(e)` case was the only
problem.
If `ui.traceback=True` is set on the server, this prints the stacktrace for the
exception on the client side. Otherwise, nothing happens. I tried allowing the
exception to propagate back to Mercurial, but then the client sees this message
with 4.4.2 and 4.6.1:
abort: remote error:
Mercurial/Python process ends with return code 1
Something odd changed when upgrading from CentOS 7.4 to 7.5 around forwarding
requests from the loopback address that I don't fully understand. First, we
were getting a ValueError from inside `opener.open()` saying that 'localhost'
didn't match the host listed in the SSL certificate. That wasn't visible until
adding this.
Then what happened is a connection refused out of the same function, so the
traceback is added to the other handler too. Running the equivalent command on
the command line from the 'vcs' host stopped working in 7.5:
$ curl https://vcs.domain.com/hook/hg/?ping=true
curl: (7) Failed connect to vcs.domain.com:443; Connection refused
But it works when run on another machine targeting that same 'vcs' host. Adding
another firewall rule allows everything to work from the 'vcs' host again:
$ iptables -t nat -I OUTPUT -p tcp -o lo --dport 443 -j REDIRECT --to-ports 8443
In SCMM v2 we use permissions. The checks are already implemented in
DefaultUserManager called by the resource.
When not authorized, the check results in an AuthorizationException,
which is mapped to 403.
As this is no longer realized in the resource, the corresponding test
is removed.
Resources are request scoped and we need only one sub resource per
request. That is, injecting all subresources (and their transitive
inejctions)in the constructor builds a lot of objects that are never
used.
Solution: Inject provider, that lazily inject the needed subresources
on demand.
