Repositories which require authentication can be cloned with bogus login data about gitblit HOT 10 CLOSED

Uh oh.  I will take a look at this very soon - maybe today.

My test setup is a little different than your setup....

* I always test on Jetty 7 (GO build) and occasionally Tomcat 6 (and Tomcat 7 in master).
* Gitblit 0.6.0 is servlet-api 2.5, not servlet-api 3.0 (Jetty 8).  The next release
is servlet-api 3.0 ready (Tomcat 6/Tomcat7/Jetty 8).
* I don't have TortoiseGit, but I don't *think* that should be an issue since the reported
error is server-side.

My preliminary result is that I can not reproduce your finding with 0.6.0 or the current
master branch.  I have tried cloning a repository at each restriction level with a
unit test.  It did surprise me to see that an empty repository is created locally,
though even though the clone failed.

Things you could do to help me diagnose the issue further:

1. Don't test on Jetty 8 since that is servlet 3.0 and may change/break authentication
(like trying to run Gitblit 0.6.0 on Tomcat 7).

2. Set "web.debugMode=true" in web.xml - this will add some logging to the AccessRestrictionFilter
class.  Confirm the received credentials in the log.  The log will say something like
when you try to clone:

INFO  ARF: ticgit.git/info/refs?service=git-upload-pack (401)
INFO  AUTH: Challenge Basic realm="Gitblit"
INFO  AUTH: invalid credentials (bogus:bogus)
INFO  ARF: ticgit.git/info/refs?service=git-upload-pack (401)
INFO  AUTH: Challenge Basic realm="Gitblit"

3. If TortoiseGit still succeeds and the credentials are the bogus ones, confirm that
the cloned repository actually has commits in it and is not just empty.

If all those are true, then perhaps TortoiseGit is falling back to the "dumb" http
protocol in which case I will have to review that some more because I did not think
that I was serving the "dumb" style.

I did not yet change back to an old Jetty version (but as I said, I used Jetty 6 at
first and had the same behaviour).
The repositories I cloned are not empty, the debug logs look like this:

INFO   | jvm 1    | 2011/10/23 18:06:59 | INFO  ARF: kake.git/info/refs?service=git-upload-pack
(401)
INFO   | jvm 1    | 2011/10/23 18:06:59 | INFO  AUTH: Challenge Basic realm="Gitblit"
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  ARF: kake.git/info/refs?service=git-upload-pack
(401)
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  AUTH: Challenge Basic realm="Gitblit"
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  AUTH: invalid credentials (bla:blub)
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  ARF: kake.git/info/refs?service=git-upload-pack
(401)
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  AUTH: Challenge Basic realm="Gitblit"
INFO   | jvm 1    | 2011/10/23 18:07:05 | INFO  ARF: kake.git/info/refs (100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/HEAD (100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/e5/8cb482d051fe0d269468d76e556f23cfb84fab
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/da/12904f9adf481ffcf1fd695e76df748542770f
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/67/f869a6b5fff28b25eb5368adff0a67ad67393c
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/18/d70f02cb8eeded3bb20b75f0cd29bb66157990
(100) unauthenticated
INFO   | jvm 1    | 2011/10/23 18:07:06 | INFO  ARF: kake.git/objects/ff/58cd936270ea2d151448f5f1cfb5a887213682
(100) unauthenticated

But it's still cloned successfully.

Ok.  Please repeat with the GO version and post your findings to help me determine where
the problem lies.

Same thing happens. I copied in one of my repositories, enabled http and started gibtlit
go locally. Then I cloned successfully from localhost using bogus login data. On Win7
with a 64bit Java7u1.
I can send you the whole thing including the repository if it helps.

That might be very diagnostic.  Try zipping and attaching to this issue - if its not
too large.  I'll install TortoiseGit to see if I can replicate here.

Oh shit.  I just replicated this with TortoiseGit.  This is obviously a nasty security
hole in my restriction filter implementation.  EGit/JGit doesn't trigger this.  Last
I checked, CGit doesn't trigger this either... but maybe it does now.  I'll check that
too.  It looks like TortoiseGit just keeps chugging along trying to make every URL
request instead of (really) stopping after authentication failure.  Actually, what
happens is that it prompts for credentials on the first challenge, but then disregards
all subsequent challenges and makes url requests which Gitblit happily processes, even
though it should not.

Thanks for reporting this.  I'll have this fixed today or tomorrow on Master.  I was
planning on a new release (big changes) by end of the week... this will be an *important*
addition.

Ah, okidoki, glad I could help, really like the software.

Fix deployed in v0.7.0.