2023-02-27 17:20:18 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='test http auth header and credential helper interop'
|
|
|
|
|
|
|
|
. ./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
|
|
|
|
'
|
|
|
|
|
|
|
|
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
|