kerberosntlmlibgit2winhttp

Why does libgit2 expose GIT_CREDENTIAL_DEFAULT as a credential type to the credential callback?


I've got a naive question about GIT_CREDENTIAL_DEFAULT. Why is it exposed to the credential callback that the clients have to implement? Can the transports not just handle this for the caller?

A server response is giving me both GIT_HTTP_AUTH_NEGOTIATE and GIT_HTTP_AUTH_NTLM, so the allowed credential types of GIT_CREDENTIAL_DEFAULT and GIT_CREDENTIAL_USERPASS_PLAINTEXT are sent to the callback. Unfortunately I check for GIT_CREDENTIAL_USERPASS_PLAINTEXT ahead of GIT_CREDENTIAL_DEFAULT. Should I just always be checking if GIT_CREDENTIAL_DEFAULT is an allowed type first and trying that before other credential types?


Solution

  • Should I just always be checking if GIT_CREDENTIAL_DEFAULT is an allowed type first and trying that before other credential types?

    Probably? This really depends on the user experience that you want to support, but I think that this is what most users would expect.

    If you were in a kerberized environment, then as a user, you would probably just expect single-signon to happen.

    You will probably need to keep some state here, however, in case you supply GIT_CREDENTIAL_DEFAULT in your callback and then the authentication fails. In this scenario, you may want to try GIT_CREDENTIAL_DEFAULT first and then prompt for username/password if that fails. (Instead of getting caught in an infinite loop just blindly trying GIT_CREDENTIAL_DEFAULT in your callback. You can use the the payload on the options structure to hold this state.)

    Why is it exposed to the credential callback that the clients have to implement? Can the transports not just handle this for the caller?

    This is a bit of a philosophical question.

    The thinking of libgit2 here is that we should not decide how to authenticate for you, the application. You can imagine that a Git GUI might try to connect to a server and then pop up a dialog that asks you how to authenticate. Maybe you want to select the currently logged in user or override that with a custom username/password.

    If you didn't want to support single sign-on then either we would need to give you an option that says you don't want it, or we need to give you the data in a credential callback so that you can choose to act on it. This is a judgement call, admittedly, but the latter seemed more in keeping with the way the library tends to work.