You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2007/01/22 19:42:40 UTC
DO NOT REPLY [Bug 41435] New: - Authentication fails with 500 Server Error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41435>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41435
Summary: Authentication fails with 500 Server Error
Product: Apache httpd-2
Version: 2.2.4
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: mod_ldap
AssignedTo: bugs@httpd.apache.org
ReportedBy: jfenlason@ptc.com
I'm running into a problem with mod_ldap on Windows. When I try to authenticate
without passing in a username, I get a 500 server error. Since the browser
doesn't get back a 401, it caches the user's credentials and I have to restart
the browser session in order to attempt to login again.
This is only happening on Windows, so I'm sure it's a difference (bug?) in the
Microsoft LDAP SDK. Below is a proposed fix on top of Apache 2.2.4. I added
the #if APR_HAS_MICROSOFT_LDAPSDK block.
modules/ldap/util_ldap.c (line 933):
/* try do the search */
if ((result = ldap_search_ext_s(ldc->ldap,
(char *)basedn, scope,
(char *)filter, attrs, 0,
NULL, NULL, NULL, -1, &res))
== LDAP_SERVER_DOWN)
{
ldc->reason = "ldap_search_ext_s() for user failed with server down";
uldap_connection_unbind(ldc);
goto start_over;
}
#if APR_HAS_MICROSOFT_LDAPSDK
if ( result == LDAP_FILTER_ERROR )
{ // no username was supplied, so fail with invalid credentials
/* failure? if so - return */
ldc->reason = "ldap_search_ext_s() to search for user failed";
ldap_msgfree(res);
uldap_connection_unbind(ldc);
return LDAP_INVALID_CREDENTIALS;
}
#endif
/* if there is an error (including LDAP_NO_SUCH_OBJECT) return now */
if (result != LDAP_SUCCESS) {
ldc->reason = "ldap_search_ext_s() for user failed";
return result;
}
It would be great if this patch or something with similar affect could be
included in the next Apache 2.2 release. Thanks.
,
Josh.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 41435] - Authentication fails with 500 Server Error
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41435>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41435
------- Additional Comments From bnicholes@apache.org 2007-01-31 14:47 -------
There is another alternative. The root of the problem is that the filter that
is being built can be interpreted by the Windows SDK as invalid if the user id
attribute is nothing. The function that creates the filter,
authn_ldap_build_filter(), already has an #ifdef for the microsoft ldap sdk.
Can you patch the code within the #ifdef to make sure that an invalid filter
for the microsoft sdk is never produced? If so, then all of the error
checking will just fall into place and there won't be a special case for
Windows when checking for a failed login.
In reality an invalid filter should result in a general error rather than an
authentication failure. A truely invalid filter could be the result of a bad
filter being passed in on the LDAP Url. If we added the special case to check
for LDAP_INVALID_FILTER that was equivalent to a failed login, then a truely
invalid filter would be reported incorrectly.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 41435] - Authentication fails with 500 Server Error
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41435>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41435
------- Additional Comments From minfrin@sharp.fm 2007-11-27 08:45 -------
Is there a valid use case for ever accepting a blank username? A possible
workaround might be to reject blank usernames entirely.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 41435] - Authentication fails with 500 Server Error
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41435>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41435
------- Additional Comments From bnicholes@apache.org 2007-01-22 11:56 -------
Unfortunately a platform specific #ifdef in util_ldap.c wouldn't be
appropriate. The easiest fix would be to add another result check at the end
of authn_ldap_check_password() in mod_authnz_ldap.c. However, the purpose of
the #ifdef's there was to handle the fact that not all platforms supported the
macro LDAP_SECURITY_ERROR() that checked a specific set of security related
result codes. Adding a check for LDAP_FILTER_ERROR doesn't seem quite right
since that result code isn't really a security code even though it would solve
the problem for Win32. The other solution would be to abstract all of the
LDAP result codes into a set of APR_LDAP_xxx codes which is probably too big
of a changed for 2.2.x.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org