Using tljh-config set for properties which require tuples, lists, dicts etc.

[davidedelvento]

Proposed change

Sometimes one needs to set a property with tljh-config set and the property needs to be something other than a string (e.g. a tuple). This is problematic because the shell interprets the parenthesis, brackets etc and so they need to be quoted or escaped. However it seems that even doing so tljh-config interprets them as strings.

One example is (from issue #406):

# A set of attribute name and value tuples a user must have to be allowed access.
c.CASAuthenticator.cas_required_attribs = {('memberOf', 'jupyterhub_users')}
sudo tljh-config set auth.CASAuthenticator.cas_required_attribs {('memberOf', 'jupyterhub_users')}

another (from current trunk of nativeauthenticator which will be released as v1.0 soon):

tljh-config set auth.NativeAuthenticator.self_approval_email ("you@example.com", "Welcome", "Click here https://${MY_IP}{approval_url}")

How could one set these non-string properties? I can think of command line switches for the tljh-config set command. E.g.

tljh-config set --tuple someproperty a b c d

which would be equivalent to creating the tuple ("a", "b", "c", "d"). And similarly for lists and dictionaries (with a little more complication for the latter).

Alternative options

The problem remains if any of the strings a b c d needs to be some other type, so perhaps a better way would be to use a different command line switch such as

tljh-config set --raw 'import foo; someproperty = (int(foo.bar()), {"agua": 23.43, "vino": foo.baz})'

the latter is obviously a quite convoluted example, but the flexibility could come handy. For my need and for simplicity, I personally prefer the option above, which simplifies the interaction with the shell itself (notice how I have a ${MY_IP} in my example above: that is an environmental variable which would be harder to inject in this alternative option).

Who would use this feature?

Everybody who will need the new nativeauthenticator v1.0 features. See for example https://native-authenticator.readthedocs.io/en/latest/options.html#allow-self-serve-approval Not released yet, but I've seen lots of interest into that.

(Optional): Suggest a solution

If there is a workaround already available, even if not as convenient as the examples above, that would be still be adequate, and the only action would be to document what to do at https://tljh.jupyter.org/en/latest/topic/authenticator-configuration.html#setting-authenticator-properties

If no other option is available, I think this must be done. If nobody is interested in doing the implementation, but you'd be ok with a PR with one of the options discussed above (or any others which we will discuss below), I could get a stab at it once we agree on the best course of action.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[manics]

You can add arbitrary extra configuration:

• https://tljh.jupyter.org/en/latest/topic/installer-actions.html#jupyterhub-config-d-directory-for-custom-configuration-snippets
• https://tljh.jupyter.org/en/latest/howto/auth/awscognito.html

[davidedelvento]

Works just fine. Perhaps a sentence or link could be added to https://tljh.jupyter.org/en/latest/topic/authenticator-configuration.html#setting-authenticator-properties about it? Not closing the issue only for that reason, otherwise it can be closed

[fredcy]

To configure for LDAP authentication I had to edit the config.yaml file directly because everything I tried for setting the bind_dn_template value via tljh-config resulted in a string value rather than a list.
It would be great if the documentation warned about the need to edit config.yaml directly in such cases.

For example, doing

sudo tljh-config set auth.LDAPAuthenticator.bind_dn_template '["uid={username},ou=Staff,ou=People,dc=example,dc=edu"]'

resulted in

bind_dn_template: '["uid={username},ou=Staff,ou=People,dc=example,dc=edu"]'

in config.yaml, and so LDAP authentication did not work.