2023-02-27 17:20:18 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='test http auth header and credential helper interop'
|
|
|
|
|
2024-05-27 11:45:56 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2023-02-27 17:20:18 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
. "$TEST_DIRECTORY"/lib-httpd.sh
|
|
|
|
|
t/lib-httpd: make CGIPassAuth support conditional
Commit 988aad99b4 (t5563: add tests for basic and anoymous HTTP access,
2023-02-27) added tests that require Apache to support the CGIPassAuth
directive, which was added in Apache 2.4.13. This is fairly old (~8
years), but recent enough that we still encounter it in the wild (e.g.,
RHEL/CentOS 7, which is not EOL until June 2024).
We can live with skipping the new tests on such a platform. But
unfortunately, since the directive is used unconditionally in our
apache.conf, it means the web server fails to start entirely, and we
cannot run other HTTP tests at all (e.g., the basic ones in t5551).
We can fix that by making the config conditional, and only triggering it
for t5563. That solves the problem for t5551 (which then ignores the
directive entirely). For t5563, we'd see apache complain in start_httpd;
with the default setting of GIT_TEST_HTTPD, we'd then skip the whole
script.
But that leaves one small problem: people may set GIT_TEST_HTTPD=1
explicitly, which instructs the tests to fail (rather than skip) when we
can't start the webserver (to avoid accidentally missing some tests).
This could be worked around by having the user manually set
GIT_SKIP_TESTS on a platform with an older Apache. But we can be a bit
friendlier by doing the version check ourselves and setting an
appropriate prereq. We'll use the (lack of) prereq to then skip the rest
of t5563. In theory we could use the prereq to skip individual tests, but
in practice this whole script depends on it.
Reported-by: Todd Zullinger <tmz@pobox.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-05-18 19:21:02 +00:00
|
|
|
enable_cgipassauth
|
|
|
|
if ! test_have_prereq CGIPASSAUTH
|
|
|
|
then
|
|
|
|
skip_all="no CGIPassAuth support"
|
|
|
|
test_done
|
|
|
|
fi
|
2023-02-27 17:20:18 +00:00
|
|
|
start_httpd
|
|
|
|
|
|
|
|
test_expect_success 'setup_credential_helper' '
|
|
|
|
mkdir "$TRASH_DIRECTORY/bin" &&
|
|
|
|
PATH=$PATH:"$TRASH_DIRECTORY/bin" &&
|
|
|
|
export PATH &&
|
|
|
|
|
|
|
|
CREDENTIAL_HELPER="$TRASH_DIRECTORY/bin/git-credential-test-helper" &&
|
|
|
|
write_script "$CREDENTIAL_HELPER" <<-\EOF
|
|
|
|
cmd=$1
|
credential: add support for multistage credential rounds
Over HTTP, NTLM and Kerberos require two rounds of authentication on the
client side. It's possible that there are custom authentication schemes
that also implement this same approach. Since these are tricky schemes
to implement and the HTTP library in use may not always handle them
gracefully on all systems, it would be helpful to allow the credential
helper to implement them instead for increased portability and
robustness.
To allow this to happen, add a boolean flag, continue, that indicates
that instead of failing when we get a 401, we should retry another round
of authentication. However, this necessitates some changes in our
current credential code so that we can make this work.
Keep the state[] headers between iterations, but only use them to send
to the helper and only consider the new ones we read from the credential
helper to be valid on subsequent iterations. That avoids us passing
stale data when we finally approve or reject the credential. Similarly,
clear the multistage and wwwauth[] values appropriately so that we
don't pass stale data or think we're trying a multiround response when
we're not. Remove the credential values so that we can actually fill a
second time with new responses.
Limit the number of iterations of reauthentication we do to 3. This
means that if there's a problem, we'll terminate with an error message
instead of retrying indefinitely and not informing the user (and
possibly conducting a DoS on the server).
In our tests, handle creating multiple response output files from our
helper so we can verify that each of the messages sent is correct.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:37 +00:00
|
|
|
teefile=$cmd-query-temp.cred
|
2023-02-27 17:20:18 +00:00
|
|
|
catfile=$cmd-reply.cred
|
|
|
|
sed -n -e "/^$/q" -e "p" >>$teefile
|
credential: add support for multistage credential rounds
Over HTTP, NTLM and Kerberos require two rounds of authentication on the
client side. It's possible that there are custom authentication schemes
that also implement this same approach. Since these are tricky schemes
to implement and the HTTP library in use may not always handle them
gracefully on all systems, it would be helpful to allow the credential
helper to implement them instead for increased portability and
robustness.
To allow this to happen, add a boolean flag, continue, that indicates
that instead of failing when we get a 401, we should retry another round
of authentication. However, this necessitates some changes in our
current credential code so that we can make this work.
Keep the state[] headers between iterations, but only use them to send
to the helper and only consider the new ones we read from the credential
helper to be valid on subsequent iterations. That avoids us passing
stale data when we finally approve or reject the credential. Similarly,
clear the multistage and wwwauth[] values appropriately so that we
don't pass stale data or think we're trying a multiround response when
we're not. Remove the credential values so that we can actually fill a
second time with new responses.
Limit the number of iterations of reauthentication we do to 3. This
means that if there's a problem, we'll terminate with an error message
instead of retrying indefinitely and not informing the user (and
possibly conducting a DoS on the server).
In our tests, handle creating multiple response output files from our
helper so we can verify that each of the messages sent is correct.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:37 +00:00
|
|
|
state=$(sed -ne "s/^state\[\]=helper://p" "$teefile")
|
|
|
|
if test -z "$state"
|
|
|
|
then
|
|
|
|
mv "$teefile" "$cmd-query.cred"
|
|
|
|
else
|
|
|
|
mv "$teefile" "$cmd-query-$state.cred"
|
|
|
|
catfile="$cmd-reply-$state.cred"
|
|
|
|
fi
|
2023-02-27 17:20:18 +00:00
|
|
|
if test "$cmd" = "get"
|
|
|
|
then
|
|
|
|
cat $catfile
|
|
|
|
fi
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
|
|
|
set_credential_reply () {
|
credential: add support for multistage credential rounds
Over HTTP, NTLM and Kerberos require two rounds of authentication on the
client side. It's possible that there are custom authentication schemes
that also implement this same approach. Since these are tricky schemes
to implement and the HTTP library in use may not always handle them
gracefully on all systems, it would be helpful to allow the credential
helper to implement them instead for increased portability and
robustness.
To allow this to happen, add a boolean flag, continue, that indicates
that instead of failing when we get a 401, we should retry another round
of authentication. However, this necessitates some changes in our
current credential code so that we can make this work.
Keep the state[] headers between iterations, but only use them to send
to the helper and only consider the new ones we read from the credential
helper to be valid on subsequent iterations. That avoids us passing
stale data when we finally approve or reject the credential. Similarly,
clear the multistage and wwwauth[] values appropriately so that we
don't pass stale data or think we're trying a multiround response when
we're not. Remove the credential values so that we can actually fill a
second time with new responses.
Limit the number of iterations of reauthentication we do to 3. This
means that if there's a problem, we'll terminate with an error message
instead of retrying indefinitely and not informing the user (and
possibly conducting a DoS on the server).
In our tests, handle creating multiple response output files from our
helper so we can verify that each of the messages sent is correct.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:37 +00:00
|
|
|
local suffix="$(test -n "$2" && echo "-$2")"
|
|
|
|
cat >"$TRASH_DIRECTORY/$1-reply$suffix.cred"
|
2023-02-27 17:20:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
expect_credential_query () {
|
credential: add support for multistage credential rounds
Over HTTP, NTLM and Kerberos require two rounds of authentication on the
client side. It's possible that there are custom authentication schemes
that also implement this same approach. Since these are tricky schemes
to implement and the HTTP library in use may not always handle them
gracefully on all systems, it would be helpful to allow the credential
helper to implement them instead for increased portability and
robustness.
To allow this to happen, add a boolean flag, continue, that indicates
that instead of failing when we get a 401, we should retry another round
of authentication. However, this necessitates some changes in our
current credential code so that we can make this work.
Keep the state[] headers between iterations, but only use them to send
to the helper and only consider the new ones we read from the credential
helper to be valid on subsequent iterations. That avoids us passing
stale data when we finally approve or reject the credential. Similarly,
clear the multistage and wwwauth[] values appropriately so that we
don't pass stale data or think we're trying a multiround response when
we're not. Remove the credential values so that we can actually fill a
second time with new responses.
Limit the number of iterations of reauthentication we do to 3. This
means that if there's a problem, we'll terminate with an error message
instead of retrying indefinitely and not informing the user (and
possibly conducting a DoS on the server).
In our tests, handle creating multiple response output files from our
helper so we can verify that each of the messages sent is correct.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:37 +00:00
|
|
|
local suffix="$(test -n "$2" && echo "-$2")"
|
|
|
|
cat >"$TRASH_DIRECTORY/$1-expect$suffix.cred" &&
|
|
|
|
test_cmp "$TRASH_DIRECTORY/$1-expect$suffix.cred" \
|
|
|
|
"$TRASH_DIRECTORY/$1-query$suffix.cred"
|
2023-02-27 17:20:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
per_test_cleanup () {
|
|
|
|
rm -f *.cred &&
|
|
|
|
rm -f "$HTTPD_ROOT_PATH"/custom-auth.valid \
|
|
|
|
"$HTTPD_ROOT_PATH"/custom-auth.challenge
|
|
|
|
}
|
|
|
|
|
|
|
|
test_expect_success 'setup repository' '
|
|
|
|
test_commit foo &&
|
|
|
|
git init --bare "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
|
|
|
|
git push --mirror "$HTTPD_DOCUMENT_ROOT_PATH/repo.git"
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'access using basic auth' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(alice:secret-passwd)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 creds=Basic YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
2023-02-27 17:20:18 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 status=200
|
|
|
|
id=default response=WWW-Authenticate: Basic realm="example.com"
|
2023-02-27 17:20:18 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
capability[]=authtype
|
2024-04-17 00:02:34 +00:00
|
|
|
capability[]=state
|
2023-02-27 17:20:18 +00:00
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
2023-02-27 17:20:20 +00:00
|
|
|
wwwauth[]=Basic realm="example.com"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store <<-EOF
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
test_expect_success 'access using basic auth via authtype' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
capability[]=authtype
|
|
|
|
authtype=Basic
|
|
|
|
credential=YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(alice:secret-passwd)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 creds=Basic YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 status=200
|
|
|
|
id=default response=WWW-Authenticate: Basic realm="example.com"
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
GIT_CURL_VERBOSE=1 git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
|
|
|
capability[]=authtype
|
2024-04-17 00:02:34 +00:00
|
|
|
capability[]=state
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=Basic realm="example.com"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store <<-EOF
|
|
|
|
capability[]=authtype
|
|
|
|
authtype=Basic
|
|
|
|
credential=YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
2023-02-27 17:20:20 +00:00
|
|
|
test_expect_success 'access using basic auth invalid credentials' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
username=baduser
|
|
|
|
password=wrong-passwd
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(alice:secret-passwd)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 creds=Basic YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
2023-02-27 17:20:20 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 status=200
|
|
|
|
id=default response=WWW-Authenticate: Basic realm="example.com"
|
2023-02-27 17:20:20 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
test_must_fail git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
capability[]=authtype
|
2024-04-17 00:02:34 +00:00
|
|
|
capability[]=state
|
2023-02-27 17:20:20 +00:00
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=Basic realm="example.com"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query erase <<-EOF
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
username=baduser
|
|
|
|
password=wrong-passwd
|
|
|
|
wwwauth[]=Basic realm="example.com"
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
http: allow authenticating proactively
When making a request over HTTP(S), Git only sends authentication if it
receives a 401 response. Thus, if a repository is open to the public
for reading, Git will typically never ask for authentication for fetches
and clones.
However, there may be times when a user would like to authenticate
nevertheless. For example, a forge may give higher rate limits to users
who authenticate because they are easier to contact in case of excessive
use. Or it may be useful for a known heavy user, such as an internal
service, to proactively authenticate so its use can be monitored and, if
necessary, throttled.
Let's make this possible with a new option, "http.proactiveAuth". This
option specifies a type of authentication which can be used to
authenticate against the host in question. This is necessary because we
lack the WWW-Authenticate header to provide us details; similarly, we
cannot accept certain types of authentication because we require
information from the server, such as a nonce or challenge, to
successfully authenticate.
If we're in auto mode and we got a username and password, set the
authentication scheme to Basic. libcurl will not send authentication
proactively unless there's a single choice of allowed authentication,
and we know in this case we didn't get an authtype entry telling us what
scheme to use, or we would have taken a different codepath and written
the header ourselves. In any event, of the other schemes that libcurl
supports, Digest and NTLM require a nonce or challenge, which means that
they cannot work with proactive auth, and GSSAPI does not use a username
and password at all, so Basic is the only logical choice among the
built-in options.
Note that the existing http_proactive_auth variable signifies proactive
auth if there are already credentials, which is different from the
functionality we're adding, which always seeks credentials even if none
are provided. Nonetheless, t5540 tests the existing behavior for
WebDAV-based pushes to an open repository without credentials, so we
preserve it. While at first this may seem an insecure and bizarre
decision, it may be that authentication is done with TLS certificates,
in which case it might actually provide a quite high level of security.
Expand the variable to use an enum to handle the additional cases and a
helper function to distinguish our new cases from the old ones.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-07-10 00:01:55 +00:00
|
|
|
test_expect_success 'access using basic proactive auth' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(alice:secret-passwd)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
|
|
|
id=1 creds=Basic YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
|
|
|
id=1 status=200
|
|
|
|
id=default status=403
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
test_config_global http.proactiveAuth basic &&
|
|
|
|
git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
|
|
|
capability[]=authtype
|
|
|
|
capability[]=state
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=Basic
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store <<-EOF
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'access using auto proactive auth with basic default' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(alice:secret-passwd)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
|
|
|
id=1 creds=Basic YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
|
|
|
id=1 status=200
|
|
|
|
id=default status=403
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
test_config_global http.proactiveAuth auto &&
|
|
|
|
git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
|
|
|
capability[]=authtype
|
|
|
|
capability[]=state
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store <<-EOF
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'access using auto proactive auth with authtype from credential helper' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
capability[]=authtype
|
|
|
|
authtype=Bearer
|
|
|
|
credential=YS1naXQtdG9rZW4=
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(a-git-token)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
|
|
|
id=1 creds=Bearer YS1naXQtdG9rZW4=
|
|
|
|
EOF
|
|
|
|
|
|
|
|
CHALLENGE="$HTTPD_ROOT_PATH/custom-auth.challenge" &&
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
|
|
|
id=1 status=200
|
|
|
|
id=default status=403
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
test_config_global http.proactiveAuth auto &&
|
|
|
|
git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
|
|
|
capability[]=authtype
|
|
|
|
capability[]=state
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store <<-EOF
|
|
|
|
capability[]=authtype
|
|
|
|
authtype=Bearer
|
|
|
|
credential=YS1naXQtdG9rZW4=
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
2023-02-27 17:20:20 +00:00
|
|
|
test_expect_success 'access using basic auth with extra challenges' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(alice:secret-passwd)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 creds=Basic YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
2023-02-27 17:20:20 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 status=200
|
|
|
|
id=default response=WWW-Authenticate: FooBar param1="value1" param2="value2"
|
|
|
|
id=default response=WWW-Authenticate: Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
id=default response=WWW-Authenticate: Basic realm="example.com"
|
2023-02-27 17:20:20 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
capability[]=authtype
|
2024-04-17 00:02:34 +00:00
|
|
|
capability[]=state
|
2023-02-27 17:20:20 +00:00
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=FooBar param1="value1" param2="value2"
|
|
|
|
wwwauth[]=Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
wwwauth[]=Basic realm="example.com"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store <<-EOF
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'access using basic auth mixed-case wwwauth header name' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(alice:secret-passwd)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 creds=Basic YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
2023-02-27 17:20:20 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 status=200
|
|
|
|
id=default response=www-authenticate: foobar param1="value1" param2="value2"
|
|
|
|
id=default response=WWW-AUTHENTICATE: BEARER authorize_uri="id.example.com" p=1 q=0
|
|
|
|
id=default response=WwW-aUtHeNtIcAtE: baSiC realm="example.com"
|
2023-02-27 17:20:20 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
capability[]=authtype
|
2024-04-17 00:02:34 +00:00
|
|
|
capability[]=state
|
2023-02-27 17:20:20 +00:00
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=foobar param1="value1" param2="value2"
|
|
|
|
wwwauth[]=BEARER authorize_uri="id.example.com" p=1 q=0
|
|
|
|
wwwauth[]=baSiC realm="example.com"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store <<-EOF
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'access using basic auth with wwwauth header continuations' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(alice:secret-passwd)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 creds=Basic YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
2023-02-27 17:20:20 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
# Note that leading and trailing whitespace is important to correctly
|
|
|
|
# simulate a continuation/folded header.
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 status=200
|
|
|
|
id=default response=WWW-Authenticate: FooBar param1="value1"
|
|
|
|
id=default response= param2="value2"
|
|
|
|
id=default response=WWW-Authenticate: Bearer authorize_uri="id.example.com"
|
|
|
|
id=default response= p=1
|
|
|
|
id=default response= q=0
|
|
|
|
id=default response=WWW-Authenticate: Basic realm="example.com"
|
2023-02-27 17:20:20 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
capability[]=authtype
|
2024-04-17 00:02:34 +00:00
|
|
|
capability[]=state
|
2023-02-27 17:20:20 +00:00
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=FooBar param1="value1" param2="value2"
|
|
|
|
wwwauth[]=Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
wwwauth[]=Basic realm="example.com"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store <<-EOF
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'access using basic auth with wwwauth header empty continuations' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(alice:secret-passwd)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 creds=Basic YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
2023-02-27 17:20:20 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
CHALLENGE="$HTTPD_ROOT_PATH/custom-auth.challenge" &&
|
|
|
|
|
|
|
|
# Note that leading and trailing whitespace is important to correctly
|
|
|
|
# simulate a continuation/folded header.
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
printf "id=1 status=200\n" >"$CHALLENGE" &&
|
|
|
|
printf "id=default response=WWW-Authenticate: FooBar param1=\"value1\"\r\n" >>"$CHALLENGE" &&
|
|
|
|
printf "id=default response= \r\n" >>"$CHALLENGE" &&
|
|
|
|
printf "id=default response= param2=\"value2\"\r\n" >>"$CHALLENGE" &&
|
|
|
|
printf "id=default response=WWW-Authenticate: Bearer authorize_uri=\"id.example.com\"\r\n" >>"$CHALLENGE" &&
|
|
|
|
printf "id=default response= p=1\r\n" >>"$CHALLENGE" &&
|
|
|
|
printf "id=default response= \r\n" >>"$CHALLENGE" &&
|
|
|
|
printf "id=default response= q=0\r\n" >>"$CHALLENGE" &&
|
|
|
|
printf "id=default response=WWW-Authenticate: Basic realm=\"example.com\"\r\n" >>"$CHALLENGE" &&
|
2023-02-27 17:20:20 +00:00
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
capability[]=authtype
|
2024-04-17 00:02:34 +00:00
|
|
|
capability[]=state
|
2023-02-27 17:20:20 +00:00
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=FooBar param1="value1" param2="value2"
|
|
|
|
wwwauth[]=Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
wwwauth[]=Basic realm="example.com"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store <<-EOF
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'access using basic auth with wwwauth header mixed line-endings' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(alice:secret-passwd)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 creds=Basic YWxpY2U6c2VjcmV0LXBhc3N3ZA==
|
2023-02-27 17:20:20 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
CHALLENGE="$HTTPD_ROOT_PATH/custom-auth.challenge" &&
|
|
|
|
|
|
|
|
# Note that leading and trailing whitespace is important to correctly
|
|
|
|
# simulate a continuation/folded header.
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
printf "id=1 status=200\n" >"$CHALLENGE" &&
|
|
|
|
printf "id=default response=WWW-Authenticate: FooBar param1=\"value1\"\r\n" >>"$CHALLENGE" &&
|
|
|
|
printf "id=default response= \r\n" >>"$CHALLENGE" &&
|
|
|
|
printf "id=default response=\tparam2=\"value2\"\r\n" >>"$CHALLENGE" &&
|
|
|
|
printf "id=default response=WWW-Authenticate: Basic realm=\"example.com\"" >>"$CHALLENGE" &&
|
2023-02-27 17:20:20 +00:00
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
capability[]=authtype
|
2024-04-17 00:02:34 +00:00
|
|
|
capability[]=state
|
2023-02-27 17:20:20 +00:00
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=FooBar param1="value1" param2="value2"
|
|
|
|
wwwauth[]=Basic realm="example.com"
|
2023-02-27 17:20:18 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store <<-EOF
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
username=alice
|
|
|
|
password=secret-passwd
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
test_expect_success 'access using bearer auth' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
capability[]=authtype
|
|
|
|
authtype=Bearer
|
|
|
|
credential=YS1naXQtdG9rZW4=
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(a-git-token)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 creds=Bearer YS1naXQtdG9rZW4=
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
CHALLENGE="$HTTPD_ROOT_PATH/custom-auth.challenge" &&
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 status=200
|
|
|
|
id=default response=WWW-Authenticate: FooBar param1="value1" param2="value2"
|
|
|
|
id=default response=WWW-Authenticate: Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
id=default response=WWW-Authenticate: Basic realm="example.com"
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
|
|
|
capability[]=authtype
|
2024-04-17 00:02:34 +00:00
|
|
|
capability[]=state
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=FooBar param1="value1" param2="value2"
|
|
|
|
wwwauth[]=Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
wwwauth[]=Basic realm="example.com"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store <<-EOF
|
|
|
|
capability[]=authtype
|
|
|
|
authtype=Bearer
|
|
|
|
credential=YS1naXQtdG9rZW4=
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'access using bearer auth with invalid credentials' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
capability[]=authtype
|
|
|
|
authtype=Bearer
|
|
|
|
credential=incorrect-token
|
|
|
|
EOF
|
|
|
|
|
|
|
|
# Basic base64(a-git-token)
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 creds=Bearer YS1naXQtdG9rZW4=
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
CHALLENGE="$HTTPD_ROOT_PATH/custom-auth.challenge" &&
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
t5563: refactor for multi-stage authentication
Some HTTP authentication schemes, such as NTLM- and Kerberos-based
options, require more than one round trip to authenticate. Currently,
these can only be supported in libcurl, since Git does not have support
for this in the credential helper protocol.
However, in a future commit, we'll add support for this functionality
into the credential helper protocol and Git itself. Because we don't
really want to implement either NTLM or Kerberos, both of which are
complex protocols, we'll want to test this using a fake credential
authentication scheme. In order to do so, update t5563 and its backend
to allow us to accept multiple sets of credentials and respond with
different behavior in each case.
Since we can now provide any number of possible status codes, provide a
non-specific reason phrase so we don't have to generate a more specific
one based on the response. The reason phrase is mandatory according to
the status-line production in RFC 7230, but clients SHOULD ignore it,
and curl does (except to print it).
Each entry in the authorization and challenge fields contains an ID,
which indicates a corresponding credential and response. If the
response is a 200 status, then we continue to execute git-http-backend.
Otherwise, we print the corresponding status and response. If no ID is
matched, we use the default response with a status of 401.
Note that there is an implicit order to the parameters. The ID is
always first and the creds or response value is always last, and
therefore may contain spaces, equals signs, or other arbitrary data.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:36 +00:00
|
|
|
id=1 status=200
|
|
|
|
id=default response=WWW-Authenticate: FooBar param1="value1" param2="value2"
|
|
|
|
id=default response=WWW-Authenticate: Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
id=default response=WWW-Authenticate: Basic realm="example.com"
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
test_must_fail git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
|
|
|
capability[]=authtype
|
2024-04-17 00:02:34 +00:00
|
|
|
capability[]=state
|
http: add support for authtype and credential
Now that we have the credential helper code set up to handle arbitrary
authentications schemes, let's add support for this in the HTTP code,
where we really want to use it. If we're using this new functionality,
don't set a username and password, and instead set a header wherever
we'd normally do so, including for proxy authentication.
Since we can now handle this case, ask the credential helper to enable
the appropriate capabilities.
Finally, if we're using the authtype value, set "Expect: 100-continue".
Any type of authentication that requires multiple rounds (such as NTLM
or Kerberos) requires a 100 Continue (if we're larger than
http.postBuffer) because otherwise we send the pack data before we're
authenticated, the push gets a 401 response, and we can't rewind the
stream. We don't know for certain what other custom schemes might
require this, the HTTP/1.1 standard has required handling this since
1999, the broken HTTP server for which we disabled this (Google's) is
now fixed and has been for some time, and libcurl has a 1-second
fallback in case the HTTP server is still broken. In addition, it is
not unreasonable to require compliance with a 25-year old standard to
use new Git features. For all of these reasons, do so here.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:32 +00:00
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=FooBar param1="value1" param2="value2"
|
|
|
|
wwwauth[]=Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
wwwauth[]=Basic realm="example.com"
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query erase <<-EOF
|
|
|
|
capability[]=authtype
|
|
|
|
authtype=Bearer
|
|
|
|
credential=incorrect-token
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=FooBar param1="value1" param2="value2"
|
|
|
|
wwwauth[]=Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
wwwauth[]=Basic realm="example.com"
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
credential: add support for multistage credential rounds
Over HTTP, NTLM and Kerberos require two rounds of authentication on the
client side. It's possible that there are custom authentication schemes
that also implement this same approach. Since these are tricky schemes
to implement and the HTTP library in use may not always handle them
gracefully on all systems, it would be helpful to allow the credential
helper to implement them instead for increased portability and
robustness.
To allow this to happen, add a boolean flag, continue, that indicates
that instead of failing when we get a 401, we should retry another round
of authentication. However, this necessitates some changes in our
current credential code so that we can make this work.
Keep the state[] headers between iterations, but only use them to send
to the helper and only consider the new ones we read from the credential
helper to be valid on subsequent iterations. That avoids us passing
stale data when we finally approve or reject the credential. Similarly,
clear the multistage and wwwauth[] values appropriately so that we
don't pass stale data or think we're trying a multiround response when
we're not. Remove the credential values so that we can actually fill a
second time with new responses.
Limit the number of iterations of reauthentication we do to 3. This
means that if there's a problem, we'll terminate with an error message
instead of retrying indefinitely and not informing the user (and
possibly conducting a DoS on the server).
In our tests, handle creating multiple response output files from our
helper so we can verify that each of the messages sent is correct.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2024-04-17 00:02:37 +00:00
|
|
|
test_expect_success 'access using three-legged auth' '
|
|
|
|
test_when_finished "per_test_cleanup" &&
|
|
|
|
|
|
|
|
set_credential_reply get <<-EOF &&
|
|
|
|
capability[]=authtype
|
|
|
|
capability[]=state
|
|
|
|
authtype=Multistage
|
|
|
|
credential=YS1naXQtdG9rZW4=
|
|
|
|
state[]=helper:foobar
|
|
|
|
continue=1
|
|
|
|
EOF
|
|
|
|
|
|
|
|
set_credential_reply get foobar <<-EOF &&
|
|
|
|
capability[]=authtype
|
|
|
|
capability[]=state
|
|
|
|
authtype=Multistage
|
|
|
|
credential=YW5vdGhlci10b2tlbg==
|
|
|
|
state[]=helper:bazquux
|
|
|
|
EOF
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.valid" <<-EOF &&
|
|
|
|
id=1 creds=Multistage YS1naXQtdG9rZW4=
|
|
|
|
id=2 creds=Multistage YW5vdGhlci10b2tlbg==
|
|
|
|
EOF
|
|
|
|
|
|
|
|
CHALLENGE="$HTTPD_ROOT_PATH/custom-auth.challenge" &&
|
|
|
|
|
|
|
|
cat >"$HTTPD_ROOT_PATH/custom-auth.challenge" <<-EOF &&
|
|
|
|
id=1 status=401 response=WWW-Authenticate: Multistage challenge="456"
|
|
|
|
id=1 status=401 response=WWW-Authenticate: Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
id=2 status=200
|
|
|
|
id=default response=WWW-Authenticate: Multistage challenge="123"
|
|
|
|
id=default response=WWW-Authenticate: Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_config_global credential.helper test-helper &&
|
|
|
|
git ls-remote "$HTTPD_URL/custom_auth/repo.git" &&
|
|
|
|
|
|
|
|
expect_credential_query get <<-EOF &&
|
|
|
|
capability[]=authtype
|
|
|
|
capability[]=state
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=Multistage challenge="123"
|
|
|
|
wwwauth[]=Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query get foobar <<-EOF &&
|
|
|
|
capability[]=authtype
|
|
|
|
capability[]=state
|
|
|
|
authtype=Multistage
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
wwwauth[]=Multistage challenge="456"
|
|
|
|
wwwauth[]=Bearer authorize_uri="id.example.com" p=1 q=0
|
|
|
|
state[]=helper:foobar
|
|
|
|
EOF
|
|
|
|
|
|
|
|
expect_credential_query store bazquux <<-EOF
|
|
|
|
capability[]=authtype
|
|
|
|
capability[]=state
|
|
|
|
authtype=Multistage
|
|
|
|
credential=YW5vdGhlci10b2tlbg==
|
|
|
|
protocol=http
|
|
|
|
host=$HTTPD_DEST
|
|
|
|
state[]=helper:bazquux
|
|
|
|
EOF
|
|
|
|
'
|
|
|
|
|
2023-02-27 17:20:18 +00:00
|
|
|
test_done
|