GetSetting() return value on empty default and configuration
-
Hey all,
hacking away at Kopano, I’ve needed to implement a configuration parameter which I can retrieve using GetSetting(). This all works fine, but I’m slightly confused as to the return value of GetSetting() on an empty (or unset) configuration parameter. Pretty much all of the instances (for string configuration options) that I found seem to rely on the fact that it returns nullptr when the configuration option is empty or not set, but this seems to contradict the defaults set up in the configuration tables, which are always the empty string, and also the logic in the GetSetting() definition. Is it safe to check whether a configuration is unset by checking it against nullptr, or (as I’m currently doing) testing it for null || strcmp(…, “”) == 0?
Thanks for any heads up.
-
Hi @modelnine,
out of curiosity. What are you working on and could this result in a patch sent in?
-
Hello Felix,
yes, this will definitely result in a patch (via a PR on GitHub), although I’m not sure if my specific use case (and implementation) is actually generally relevant.
I have a specific requirement in the (active) directory that I’m using Kopano for to be able to define user accounts (i.e., objectClass=user, having a login), which are Kopano objects (exposed for the mailserver for mail forwarding and also as entries in the GAB, i.e. kopanoAccount=1), but which are not ACTIVE_USER(s), but rather NONACTIVE_CONTACT objects, as they should not have a mailbox. Due to the fact that the two Kopano object classes are currently only differentiable through their objectClass (there are no other filters applicable to decide whether something is a user/mailbox, or a contact when found by the ldap_user_search_filter, and there’s no “contact” user type, but just non-active mailbox types), I’ve implemented somewhat of a generic hack: I’m using a new configuration option (ldap_user_local_attribute) to define an attribute, which - when set (to any value) on the underlying LDAP object - signals that the user is a “local” user for Kopano, i.e. a user/mailbox, whereas when it’s not set, signals that the user is non-local for the Kopano server and should be represented as a contact. My current implementation is generic enough that simply leaving the configuration blank (no value set up for ldap_user_local_attribute) tells the system to go back to the normal functionality of only deciding based on the objectClass; that’s why I asked this specific question, as with the additional checks for strcmp(, “”) the code currently looks… not so nice. ;-)
The reasoning behind choosing an attribute to represent the state differentiation like this is that it fits in nicely with the kopanoUserServer attribute: when the attribute is clear, the user has “no server”, and as such is non-local, when it’s set, there’s a Kopano server in the current group hosting the mailbox, and so it’s local. I know that the field isn’t relevant for other parts of the system to non-multiserver deployments (which is the case in my case), but as it’s easily settable through the ADUC plugin, it’s something that made sense to me. Another possibility would have been to check with a filter something like if the primary mail address is in the local domain, but that’s much more complicated and not easily extensible and visible through ADUC itself.
I’m currently testing the adaptation (thank you for having a clean codebase - implementing this was actually easy!), and will then post a PR against branch 8.7.x. Possibly, someone else also has a use-case for this.
-
GetSetting(x) returns nullptr if x is not in the table; otherwise it yields the set value, or the default from the table.
-
Thanks, @jengelh, that’s what I gathered from reading the GetSetting() code itself. In that case, why are there so many non-NULL-checks in LDAPUserPlugin.cpp for configuration variables? I’d gather they make no sense, because all options have defaults (the empty string); that’s where my initial confusion came from.
