Univention Bugzilla – Bug 51817
43_proxy/07_basic_auth_encoding fails in UCS 5.0
Last modified: 2021-10-29 17:06:22 CEST
43_proxy/07_basic_auth_encoding fails in UCS 5.0: Create squid/basicauth File: /etc/squid/squid.conf W: The config registry variable 'squid/ntlmauth' does not exist Reconfigure squid Creating users/user object with /usr/sbin/udm-test users/user create --position cn=users,dc=autotest090,dc=local --set username=umlaut --set lastname=mtb6gcgldd --set 'password=ünivention' --set firstname=r8olebgang Now checking encoding: utf8 Username: umlaut, Password: ünivention Using credentials: dW1sYXV0OsO8bml2ZW50aW9u Success ########################## Now checking encoding: iso-8859-1 Username: umlaut, Password: ünivention Using credentials: dW1sYXV0OvxuaXZlbnRpb24= Cleanup after exception: <class 'subprocess.CalledProcessError'> Command '['curl', '--fail', '--silent', '--output', '/dev/null', '--proxy', 'localhost:3128', '--header', 'Proxy-Authorization: Basic dW1sYXV0OvxuaXZlbnRpb24=', '--url', 'http://www.univention.de/']' returned non-zero exit status 22 Performing UCSTestUDM cleanup... removing DN: uid=umlaut,cn=users,dc=autotest090,dc=local Cleanup: wait for replication and drs removal OpenLDAP object to check against S4-Connector match_filter doesn't exist: uid=umlaut,cn=users,dc=autotest090,dc=local DRS wait not required, S4-Connector match_filter did not match the OpenLDAP object: uid=umlaut,cn=users,dc=autotest090,dc=local trying to restart UDM CLI server sending signal 15 to process 23570 (['/usr/bin/python3', '/usr/share/univention-directory-manager-tools/univention-cli-server']) process already terminated UCSTestUDM cleanup done Unsetting squid/basicauth File: /etc/squid/squid.conf Traceback (most recent call last): File "07_basic_auth_encoding", line 92, in <module> main() File "07_basic_auth_encoding", line 75, in main check_proxy(user, encoding) File "07_basic_auth_encoding", line 52, in check_proxy url, File "/usr/lib/python2.7/subprocess.py", line 190, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['curl', '--fail', '--silent', '--output', '/dev/null', '--proxy', 'localhost:3128', '--header', 'Proxy-Authorization: Basic dW1sYXV0OvxuaXZlbnRpb24=', '--url', 'http://www.univention.de/']' returned non-zero exit status 22 → dW1sYXV0OvxuaXZlbnRpb24= is b"umlaut:\xfcnivention" (latin-1 / ISO8859-1: umlaut:ünivention) Please re-enable the test case when this is fixed.
basic_ldap_auth changed in 4.6: ======================================================================= Changes to squid-4.6 (08 Feb 2019): - [...] - basic_ldap_auth: Return BH on internal errors; polished messages ======================================================================= https://github.com/squid-cache/squid/commit/53641f9dd55fb9b7ab4aadd158f7f11605fe90e5#diff-b96e29fa666c9d5e243de8c34144b9fdd8d62b499cb1dc03b3cfcbdf48df5add I adjusted the basic_ldap_auth_encoding_wrapper accordingly. 1713294541 | fix and UCS-5 changelog Package: univention-squid Version: 13.0.2-1A~5.0.0.202103032041 Branch: ucs_5.0-0
Changes -> OK Test 07_basic_auth_encoding -> OK Changelog (fixed bug number) -> OK -> Verified
UCS 5.0 has been released: https://docs.software-univention.de/release-notes-5.0-0-en.html https://docs.software-univention.de/release-notes-5.0-0-de.html If this error occurs again, please use "Clone This Bug".
I just had to do with this again and I am unsure if our fix is the best choice. There are 3 possible responses (https://wiki.squid-cache.org/Features/AddonHelpers): OK | Success. Valid credentials. ERR | Success. Invalid credentials. BH | Failure. The helper encountered a problem. The helper now sends "BH Success" while it should send "ERR Success". So, what did the upstream patch change? (https://github.com/squid-cache/squid/commit/53641f9dd55fb9b7ab4aadd158f7f11605fe90e5): > if (LDAP_SECURITY_ERROR(e)) > SEND_ERR(ldap_err2string(e)); > else > SEND_BH(ldap_err2string(e)); (→ That's the only place where a BH response is done.) And what is LDAP_SECURITY_ERROR?: openldap/include/ldap.h: > #define LDAP_SECURITY_ERROR(n)» LDAP_RANGE((n),0x2F,0x32) /* 47-50 */ > > #define LDAP_X_PROXY_AUTHZ_FAILURE» 0x2F /* LDAPv3 proxy authorization */ > #define LDAP_INAPPROPRIATE_AUTH»» 0x30 > #define LDAP_INVALID_CREDENTIALS» 0x31 > #define LDAP_INSUFFICIENT_ACCESS» 0x32 So, the original helper doesn't response with `LDAP_INVALID_CREDENTIALS` anymore on a LDAP bind? Why not? What does it respond with? With the patch we applied our helper wouldn't work anymore if the the response would be `LDAP_INVALID_CREDENTIALS` again. So we should at least support both. Or better fix the reason, so that it returns the regular "ERR Success" again.