当我拥有的唯一参数是用户 ID 时,我正在尝试获取用户的 DN(可能不止一个)
正如您所看到的,我也在使用 UnboundID LDAP SDK:
public String getCustomerAdminDN(String uid)
{
String result =null;
String filter = "uid=" +uid;
try {
SearchResult searchResult = this.ldapConnection.search("",SearchScope.SUB,filter);
result = searchResult.getMatchedDN();
} catch (LDAPSearchException e) {
throw new RuntimeException("Error in the searching query :" + e.getMessage());
}
return result;
}
Run Code Online (Sandbox Code Playgroud)
让我们假设我的 uid 属于以下 DN
一个人的感谢
小智 5
在这种情况下的问题是“匹配的 DN”元素不是您认为的那样。它不是与搜索条件匹配的条目的 DN(实际上可能是零、一个或多个条目)。如果操作的目标不存在,则可以提供响应的匹配 DN 元素。对于搜索操作,如果您指定了一个不存在的搜索基础 DN,那么匹配的 DN 可能会指定与您指定的在服务器中实际存在的条目最接近的条目的 DN。例如,如果您指定的搜索基础 DN 为“ou=nonexistent,dc=example,dc=com”,但该条目不存在但条目“dc=example,dc=com”条目确实存在,则服务器可能会返回匹配的 DN 值“dc=example,dc=com”。
如果您的搜索与一个或多个条目匹配,那么(除非您使用了搜索结果侦听器,在您上面提供的示例中并非如此),匹配的条目将可以通过 getSearchEntries 方法访问。例如:
List<SearchResultEntry> searchEntries = searchResult.getSearchEntries();
if (searchEntries.size() != 1)
{
// The search didn't match exactly one entry.
}
else
{
SearchResultEntry entry = searchEntries.get(0);
result = entry.getDN();
}
Run Code Online (Sandbox Code Playgroud)
此外,当部分值可能来自用户输入时,从它们的字符串表示构造过滤器时应该小心,因为这可能允许某种注入攻击。LDAP 注入比 SQL 更困难,通常也更温和,但并非完全不存在。因此,建议改为:
String filter = "uid=" + uid;
Run Code Online (Sandbox Code Playgroud)
你用:
Filter filter = Filter.createEqualityFilter("uid", uid);
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
8687 次 |
| 最近记录: |