Github user mike-jumper commented on a diff in the pull request:
https://github.com/apache/incubator-guacamole-client/pull/131#discussion_r106820666
--- Diff:
extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/ConfigurationService.java
---
@@ -223,4 +223,36 @@ public int getMaxResults() throws GuacamoleException {
);
}
+ /**
+ * Returns whether or not LDAP aliases will be dereferenced,
+ * as configured with guacamole.properties.
+ * By default they will never be dereferenced.
+ *
+ * @return
+ * An integer representing the status of of alias
+ * dereferencing, as configured in guacamole.properties.
+ *
+ * @throws GuacamoleException
+ * If guacamole.properties cannot be parsed.
+ */
+ public int getDereferenceAliases() throws GuacamoleException {
+ String derefAliases = environment.getProperty(
+ LDAPGuacamoleProperties.LDAP_DEREFERENCE_ALIASES,
+ "never"
+ );
+
+ if (derefAliases == "always")
+ return 3;
--- End diff --
[`LDAPSearchConstraints`](https://www.novell.com/documentation/developer/jldap/jldapenu/api/com/novell/ldap/LDAPSearchConstraints.html)
defines constants for these values (`DEREF_ALWAYS`, `DEREF_FINDING`, ...). We
should be using those, rather than hard-coding their low-level integer values.
That said, I'm not sure this is really a good way to achieve this. We're
essentially marrying Guacamole's configuration to the internals of JLDAP, which
definitely violates separation of concerns. If the internals of JLDAP happened
to just make that much sense, then OK, but "always", "finding", "searching",
and "never" don't really make intuitive sense.
If `ConfigurationService` will ultimately return the integer that
`LDAPSearchConstraints` requires, that's OK - it's internal to the extension,
and `ConfigurationService` itself separates that concern from that of the
configuration, but you don't want to violate that separation by essentially
mapping internals directly to `guacamole.properties`. Ideally, you'd determine
a sensible set of values based on the behaviors that the LDAP auth should
support, and then translate those into the values required by JLDAP.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
