Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 53273 invoked by uid 500); 12 Dec 2002 22:59:34 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 53246 invoked from network); 12 Dec 2002 22:59:34 -0000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Beta Date: Thu, 12 Dec 2002 15:59:29 -0700 From: "Brad Nicholes" To: ,, Subject: Re: [PATCH-3] Allowing extended characters in LDAP authentication... Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Rating: daedalus.apache.org 1.6.2 500/1000/N You are absolutely right, there are other modules that need to do = header conversion. In a previous email, Bill Rowe pointed out that WebDAV = also suffers from charset mismatch, but in a different way than auth_ldap. = WebDAV needs the URI converted as well as other header entries in order = to function correctly. A generalized solution needs to be worked out, but = even a generalized header conversion solution still may not solve the = problem for authentication modules because of the fact that the authenticat= ion data conversion needs to be done at the point when the data is = decrypted. In order to solve WebDAV's problem, the scope of this = discussion needs to be much broader. Any ideas?? Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com=20 >>> kess@kess-net.de Thursday, December 12, 2002 2:07:24 PM >>> > The charset conversion that is happening in LDAP is actually quite > specialized. The general functionality of converting from one charset > to another already exists in APR in the form of apr_xlat_xxx(). LDAP is > only interested in converting the user ID from a given charset to UTF-8. > Up until auth_ldap calls ap_get_basic_auth_pw(), the user ID and > password are encrypted in the "Authentication" header entry. Until the > user ID and password have been decrypted, the conversion to UTF-8 can > not occur. Therefore the conversion must take place from within > auth_ldap or any other authentication module after decrypting the user > information. A module or filter outside of the authentication module > that does a blind charset conversion on the header information, would > not work because it would not be able to decrypt the user ID and > password, convert it and re-encrypt it in order to make the process > transparent to all authentication modules. =20 Well you are right, that you first have to decrypt the authentication=20 information before you are able to do charset conversion. And I overlooked= =20 that a conversion function already exists, which you are using. My=20 suggestions have been a little bit inconsideratly. Let me try to explain. > I do agree that we need some type of functionality that will convert > requests made in a particular charset to a universal charset that Apache > can rely on. I'm just not sure this is it. It seems to work for > auth_LDAP, but I'm not sure how to generalize it. This is where a much > broader discussion need to take place. I still think mod_auth_ldap won't be the only module doing charset=20 conversion on headers. Or say, the authentication header might not stay = the=20 only header which needs to be converted. But if we want to convert = headers=20 and we have to guess the incoming charset, we will need a general=20 assignment table, not only for mod_auth_ldap but for all modules interested= =20 in converting headers. Or with other words, your conf file might move = to=20 another module at a later time. Which could also be done now.=20 But maybe this patch is not the right place to discuss a general new=20 feature. Kess