Re: How to debug BASIC authentication and/or authorization when cloning gerrit-hosted projects

[Christian Halstrick]

Hi,

I found out that it is the ProjectDigestFilter who denies the request.
The authorization header of the failing request is

Basic RDA.....=
(I replaced some characters by ...)

But the ProjectDigestFilter only accepts a authorization header
starting with "Digest ". What's the logic behind this? Can
I access gerrit below "/p" with authorization header set to "Basic: ..."?

Ciao
Chris

[Christian Halstrick]

Hi,

I have a gerrit server which is configured to use container-based
basic authentication. Access to gerrits Web-UI works. But I get "403
Forbidden" responses when I try to clone the repo with msysgit. Seems
that authentication went through but authorization now doesn't allow
me to clone. Now I want to debug gerrit to see why I get this response
but I can't find a good place for a breakpoint.

By typing "GIT_CURL_VERBOSE=1 git clone
https://D03...@gerritgerritsap.prod.jpaas.sapbydesign.com/g/p/tgi/ldi.ui.things"
I see that it is a "> GET /g/p/tgi/ldi.ui.things/info/refs HTTP/1.1"
request which get's the 403 response. Does anybody know a good place
where to place a breakpoint to see whats going on?

Ciao
  Chris

[Shawn Pearce]

No, not in the current code.

We only support digest authentication to protect the password; if the
site is not using SSL a basic authentication is sending the password
in the clear on the network. Since Gerrit has little control over the
frontend proxy (if it exists), its defensively assuming the connection
is not secure and uses digest to reduce the risk the password is
leaked.

If you want to contribute basic support that is available when the
request is secure or the site administrator has enabled it in
gerrit.config, it should be a lot easier than the digest logic. :-)

[Christian Halstrick]

ok, I understand that and why we currently don't have BASIC
authentication. But ideally in my use-case gerrit shouldn't
authenticate at all. I would like to have container based
authentication and gerrit should simply trust then container. I am
using gerrit currently in an container which does a lot of
complicated, company-specific stuff to authenticate users. Can I
configure gerrit just to trust the container and never try to
authenticate himself?

[Alex Blewitt]

Yes, use http (or http_ldap) and set this:

auth.httpHeader

HTTP header to trust the username from, or unset to select HTTP basic or digest authentication. Only used if auth.type was set to HTTP.

[Shawn Pearce]

On 25 Aug 2011, at 07:56, Christian Halstrick
<christian...@gmail.com> wrote:
>
> ok, I understand that and why we currently don't have BASIC
> authentication. But ideally in my use-case gerrit shouldn't
> authenticate at all. I would like to have container based
> authentication and gerrit should simply trust then container. I am
> using gerrit currently in an container which does a lot of
> complicated, company-specific stuff to authenticate users. Can I
> configure gerrit just to trust the container and never try to
> authenticate himself?

I didn't consider this. This may be easier than supporting HTTP Basic.
Add a new setting to gerrit.config to trust the container
authentication for the /p/ URL, and configure a different filter in
the servlet pipeline that checks the container auth to get the
Account.Id rather than using the ProjectDigestFilter.

On Thu, Aug 25, 2011 at 00:47, Alex Blewitt <alex.b...@gmail.com> wrote:
> Yes, use http (or http_ldap) and set this:
> auth.httpHeader
>
> HTTP header to trust the username from, or unset to select HTTP basic or
> digest authentication. Only used if auth.type was set to HTTP.

Doesn't work for the Git over HTTP case. Git over HTTP requires using
the Gerrit generated HTTP password.

[Christian Halstrick]

> I didn't consider this. This may be easier than supporting HTTP Basic.
> Add a new setting to gerrit.config to trust the container
> authentication for the /p/ URL, and configure a different filter in
> the servlet pipeline that checks the container auth to get the
> Account.Id rather than using the ProjectDigestFilter.

There is auth.httpheader and the docu says: "HTTP header to trust the
username from ...".
Strange that we need for Git over HTTP another config parameter. On
the other hand:
In our case there is no HTTP Header which contains the
container-authenticated user.
But there is a attribute of request where the container puts the
authenticated user and
I can access this user by calling request.getRemoteUser(). The new
Filter would do
something like:

.....
String username = req.getRemoteUser();
final AccountState who = accountCache.getByUsername(username);
session.get().setUserAccountId(who.getAccount().getId());
....

Correct?

[Christian Halstrick]

Hi,

the latest proposal for allowing gerrit to trust container based
authentications is available under
https://review.source.android.com/#/c/25804/4.

Ciao
  Chris