LDAP Gerrit authentication over Http
gprs
Shawn Pearce
> Is it possible to authenticate a LDAP user on Gerrit over Http (using curl
> or something) ?
No, not currently. You might be able to get close by using client side
SSL certificates, but then you also have to enable that across
everything in Gerrit.
Can I ask what you are trying to do? Maybe there is an alternative
that is workable at the present tim?
Gaurav Shah
I am writing a command line tool which needs to read the contents of the file over http via gitweb.I construct the gitweb url to that file by embedding the known SHA1. Gitweb has been secured by redirecting it via gerrit which needs LDAP authentication. My command line tool is in Java.
Shawn Pearce
>
> I am writing a command line tool which needs to read the contents of the
> file over http via gitweb.I construct the gitweb url to that file by
> embedding the known SHA1. Gitweb has been secured by redirecting it via
> gerrit which needs LDAP authentication. My command line tool is in Java.
Clone the repository and fetch the file from the local copy?
Phil Lawrence
On Apr 6, 10:07 am, Shawn Pearce <s...@google.com> wrote:
>
> > I am writing a command line tool which needs to read the contents of the
> > file over http via gitweb.I construct the gitweb url to that file by
> > embedding the known SHA1. Gitweb has been secured by redirecting it via
> > gerrit which needs LDAP authentication. My command line tool is in Java.
>
> Clone the repository and fetch the file from the local copy?
secured, i.e. it is a Gerrit "Internal/Managed gitweb." Is there any
way to script the Gerrit authentication, thus allowing scripted access
to gitweb?
I was hoping something like Perl's LWP::UserAgent could do the initial
authentication and then save the cookie, allowing the script to access
gitweb.
However, someone else working on this noted:
> Most websites I’ve seen using Basic http auth, cause a browser-native
> dialog box to popup in response to a some kind of a basic auth challenge
> http response (error code 401). The Gerrit link I saw, uses a coded JS
> input form. At first glance, hence, this doesn’t appear to be a case of basic
> auth.
>
> Now it may be that clicking the “Sign in” link at the top issues an http reques
> (via JS I’m guessing) to some URL which in turn responds with a 401 error
> challenge. We’d at least need to know that URL to start with – we tried
> decoding the JS dialog box but the JS code we saw was non-trivial to walk
> through.
Shawn Pearce
> On Apr 6, 10:07 am, Shawn Pearce <s...@google.com> wrote:
>> On Fri, Apr 6, 2012 at 00:55, Gaurav Shah <gauravworld2...@gmail.com> wrote:
>>
>> > I am writing a command line tool which needs to read the contents of the
>> > file over http via gitweb.I construct the gitweb url to that file by
>> > embedding the known SHA1. Gitweb has been secured by redirecting it via
>> > gerrit which needs LDAP authentication. My command line tool is in Java.
>>
>> Clone the repository and fetch the file from the local copy?
>
> We have Gerrit set up with an auth.type of LDAP, and gitweb is
> secured, i.e. it is a Gerrit "Internal/Managed gitweb." Is there any
> way to script the Gerrit authentication, thus allowing scripted access
> to gitweb?
>
> I was hoping something like Perl's LWP::UserAgent could do the initial
> authentication and then save the cookie, allowing the script to access
> gitweb.
This is still possible, its just a bit of work to get the request
phrased right to get the cookie. :-(
> However, someone else working on this noted:
>> Most websites I’ve seen using Basic http auth, cause a browser-native
>> dialog box to popup in response to a some kind of a basic auth challenge
>> http response (error code 401). The Gerrit link I saw, uses a coded JS
>> input form. At first glance, hence, this doesn’t appear to be a case of basic
>> auth.
Its not HTTP basic auth. Basic auth has a ton of problems. Since the
browser vendors never fixed authentication, site owners went and built
their own solutions in HTML. Since site owners built their own
solutions in HTML, browser vendors were never motivated to make
browser based authentication work. And so on. I'm not happy this is
the still state of the web now 15 years later.
>> Now it may be that clicking the “Sign in” link at the top issues an http reques
>> (via JS I’m guessing) to some URL which in turn responds with a 401 error
>> challenge. We’d at least need to know that URL to start with – we tried
>> decoding the JS dialog box but the JS code we saw was non-trivial to walk
>> through.
Don't try to dig into the JavaScript. Its obfuscated and compressed to
save transfer space and make it load faster in the browser's parser.
Use the developer tools feature of your browser to inspect the XHR
network request the JavaScript makes when you sign-in. It should be
doing a POST to the /gerrit/rpc/UserPassAuthService. The POST is a
JSON-RPC 2.0 request containing the username and password as
positional arguments.
The response will be a small JSON that says nothing, or an error. If
there was no error, there should also be a Set-Cookie header supplying
you with a cookie named GerritAccount. This cookie will provide
authentication in future requests.