Enabling features

[girish]

@msbt mm, so while that MR works, it goes against our philosophy of code being readonly at runtime. Wondering if there are any strong reasons to do this. After all, we can just enable the necessary features in the package. Things like --db etc should not be changed by users (the manifest addons are static)

[msbt]

@girish the problem is that if you add a new provider, the executable needs a rebuild, else it won't recognize it (as far as I understand it)

[msbt]

@girish https://www.keycloak.org/server/configuration-provider#_installing_and_uninstalling_a_provider

[girish]

@msbt ah ok, this is for providers and not this features thing. So, in your case, there is a custom provider jar file and we have to rebuild keycloak with that?

[girish]

mm, I see. Even setting some provider configuration requires a rebuild.. crazy

[gpichler]

Yes it's mainly about providers. Changing features is an additional option. I do not think it would be wise to include all possible providers and features upstream whenever a user requests them.

[shrey]

@girish is there any workaround/solution planned for this (capability to add/modify features)?

Example, i'm trying to add SMS Auth and Webhook Events capabilities, by first adding the .jar files to the providers folder > add/edit the corresponding conf/env variables in keycloak.conf > trigger the build operation. But it simply restarts the container, while removing all of my changes to the .conf file.

[gpichler]

@shrey You could try my patch in the MR https://git.cloudron.io/packages/keycloak-app/-/merge_requests/12 :
Add the .jar in the providers/, add additional commandline flags in env.sh and then simply restart the container.

[girish]

@gpichler @shrey we will try to get the MR merged soonish . Just have to double check if there is any other workaround we can use because we really dislike code being writable!

[gpichler]

@girish Out of curiosity: What is your rational for not liking code being writable? Is it a security consideration?

[nebulon]

Security is one but equally important is it for updating apps. If code files are changed we can't test and validate updates and each update will overwrite any local changes anyways.

[gpichler]

I see. In the case of this MR, the executable (the .jar file) is rebuilt on every app startup. Thus, this would not be overwritten by an update. The relevant commandline parameters are persistent in env.sh when updating.

I think there are two failure modes after an update: 1) obsolete commandline parameters in env.sh or 2) .jar files in providers/, which were compatible with the previous version but incompatible with the new version. If you want to allow users to select custom features and install custom providers. I think both these options are essentially unavoidable.

Let me know if there is something I can improve. I am looking forward to getting this merged.

[girish]

@gpichler @msbt I have merged it now and published it