Cannot clone a git repo protected with .htaccess

[cplr]

I have a private git repo that is protected with an .htaccess file, with a username/password. For example:

http://username:password@www.example.com/git/project.git

I would expect to be able to clone the repo with the full URL like above, but ideally I would like to be able to enter the username/password using the already provided text fields, and have the password saved using the iOS keychain.

[SquaredTiki]

Thanks for the feedback. At present if you use the full URL (as in your example), does it work or is an error shown? If the latter then would you be able to post a screenshot of the error message? Thanks!

[cplr]

The error says:

Clone failed Failed to clone repository from http://uname:pass@www.ex.com/git/project.git to file://var/mobile/Containers/Data/Application/AppID/Documents/Identifier

Invalid Content-Type: text/plain.

[SquaredTiki]

Are you able to clone the repo using git and HTTP basic authentication from the Terminal on your Mac?

[cplr]

Yep, this is what the repo config file looks like:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[remote "origin"]
    url = http://user@www.url.com/git/proj.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master

without the password embedded in the URL, git will request the password as needed. It also works if I embed the password in there, but then it's stored as plain-text so that's not that great. I use SourceTree as a GUI for basic operations, and that has the capability to use the login keychain for storing and using the password.

[SquaredTiki]

I see, thanks. I will try to recreate this myself though it already appears that libgit is a little more picky than the git command in what it can clone.

[SquaredTiki]

The error you are receiving occurs when a Content-Type not matching the format of application/x-git-<service>-advertisement is provided by the server when cloning (e.g. the Content-Type is not x-git-receive-pack-advertisement or x-git-upload-pack-advertisement). See this post on SO for more info: http://stackoverflow.com/a/18588665

[cplr]

Interesting! I will make some adjustments to my .htaccess to return the right types, and see if that fixes it. Will report back.

[cplr]

OK, so I finally got around to reconfiguring my git server (following this guide, for use with Dreamiest: https://github.com/tmacam/private-git-on-dreamhost), which uses Smart HTTP, etc, and I thought would fix this issue, however now I get a different error, which is "Unexpected HTTP status code: 401" even if I put both the username and password into the URL field.

[SquaredTiki]

Does doing the same work from your Mac? For example trying to access the URL through the browser and authenticating or trying to clone through the git command on the Mac?

[cplr]

yeah, it works just fine on the command line

[SquaredTiki]

I will try to recreate this myself using that guide. If you remove authentication as per the 'Troubleshooting' section in the guide, are you able to clone?

[cplr]

Yeah, it works fine if I disable the .htaccess. For now I will hide this behind some crazy URL so I can use Dringend :) thankfully with that tutorial, it forwards to a private repo, so it's easy to change the public URL...

[SquaredTiki]

Glad to hear there is at least a work around :) I will continue to look into this and am attempting to get a local git server set up as we speak to test this

[SquaredTiki]

@cplr After setting this up myself and experiencing the same issue, it appears to be due to the fact that the set-up uses AuthType Digest. From what I can see the libgit library does not support this authentication type and rather only supports AuthType Basic. This log in Apache's error_log gave it away:

Client used wrong authentication scheme 'Basic' in request for URI /corporate-git/BrandNewGit.git/info/refs

And upon further research in threads regarding libgit itself, it appears that Digest is not supported and it will always use HTTP Basic authentication. Switching over to AuthType Basic in .htaccess and re-creating .htpasswd appropriately fixed the issue for me.

[cplr]

This is great news - thanks.

[cplr]

just confirming, I switched to AuthType Basic and it's working perfectly :). Thanks for your assistance.

[SquaredTiki]

No worries, glad it's all working now :)