Kallithea issues archive

Issue #155: Error authenticating

Reported by: Zachary Kent
State: resolved
Created on: 2015-09-04 15:55
Updated on: 2015-09-08 18:08


I have cloned our Git repo to our DEV server so we can just pull the changes easily to the server. However I was the first one to do so and used the URL https://zachary.kent@ourdomain.com/path/to/my/repo. When I do a pull from the DEV server, I am asked for my password and the operation works fine. However, when my co-workers attempt this, it fails because its attempting to authenticate @zachary.kent. How can I fix this so they can also use this repo.

Error they are getting: error: The requested URL returned error: 401 while accessing https://zachary.kent@ourdomain.com/path/to/my/repo/info/refs (note my name in the URL)



Comment by Mads Kiilerich, on 2015-09-07 11:45

I think that is a git question more than a Kallithea question.

I guess git (like Mercurial) has a way to update the address of an external reference.

Comment by Zachary Kent, on 2015-09-08 15:10

I updated the upstream URL and removed the zachary.kent@ part of the URL and it would no longer connect. Could this be a setting in our Kallithea setup? We are using LDAP.

Comment by Søren Løvborg, on 2015-09-08 16:03

This is not a Kallithea issue, but a Git client issue. Ensure that your remotes are set up correctly (view them using git remote -v; more info: git remote --help).

If different users are sharing the same repository clone, the remotes should of course not include username or password; then Git will ask for username and password on every push and fetch operation. (If the users are using different user accounts on the server, Git can be configured to remember the credentials per user; see git credentials --help).

Comment by Zachary Kent, on 2015-09-08 16:19

You are correct. I found this article http://stackoverflow.com/a/12538716/18779 and since our server has Git version 1.7.1, I have to include at least the username in the URL.

Comment by Zachary Kent, on 2015-09-08 16:20

The issue is because our server's version of Git (1.7.1)

Comment by Søren Løvborg, on 2015-09-08 18:08

Never encountered that bug. :-) Unfortunately, Git 1.7.1 is more than 5 years old and very outdated, even as it's still the standard on some enterprise distros.

Even just 1.7.11 is a big step forward compared to 1.7.1; but I would highly recommend upgrading to as recent a version as is feasible.