Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upadding dynamic env var support for external oauth service #1922
Conversation
|
I'm a little bit confused, if I got this right, whenever custom is active and a CUSTOM_ value is present, it's automatically added to the schema? Or it needs to be registered by the extension? Also, I'm a little bit concerned because it seems bounded to auth extensions only because of the changes made to CoreServiceProvider file, but it would be useful for other extensions right? Please let me know if I'm missing something. |
|
@WoLfulus that is correct. I guess overall it would be way better to provide an extension the option with an interface or a trait to add to the config schema by itself. To be honest, I implemented it only within the oauth because we only used a couple extensions here which all worked, so I assumed that loading stuff is handled correctly there. I can rework this into a trait scenario which gives the extension the option to add its own schema-part to the config. that would get rid of a bit of the code right now because one must not define the schema and pass on the data for it within the env vars. |
|
That would be awesome. Just need to make sure it has a default behavior/impl on base classes to avoid breaking extensions. Another option would be letting the extensions use schemas and loading configs on their own on initialization. I don't remember if the config and schemas are properly decoupled and has a good interface for that. Let's see what @rijkvanzanten thinks. |
updated schema to register against node
|
@WoLfulus Ok, so the trait is all set up, the only thing I am struggling with right now is, where should the trait be checked for and loaded? because if it is done, and that would be the earliest time, when the class is loaded, it would be loaded, in the auth scenario, when all config related parts are already loaded. So it would be better if it would have been registered somewhere before. Is there a registry for extensions/custom ssos which I do not see which may preload the files and could then add the trait from the Provider.php eg? |
Trait and Interface gets new function to read the actual custom schema to be added CoreServicesProvider.php changed the load of get_custom_x to be loaded before the Schema gets loaded so the changes are before the config will be loaded
…ly defined. on error a log will be written
|
Ok, I changed a couple of things. To add new stuff to schema, I got it, how I think, to a good decoupled way. an extension, wherever it lies, now can provide a CustomSchema.php The implementation of the trait and the interface ensures that a) a specific path can be added for the config and it returns the schema to be added. as far as I have seen, the get_custom_x is only called within the getExternalAuth for the providers. This piece should maybe also implemented somewhere else. Curious about your view on this parts. in my opinion, this now leaves the config to the extension or the provider or whatever extension there is and have it being loaded before the schema is loaded and that giving an extension the option to add values to the config which then can be used after the config is loaded. |
The problem:
I was deploying directus/directus from the base image onto a kubernetes instance via a helm chart and making the configurations via env vars.
I added our extensions for our SSO (keycloak) via a folder and added that into the pod / container.
It turned out however, that no matter what I did, the keycloak was not loaded and I would have to create an api.php containing all the settings I need as a config file including our keycloak config. That would kill my flexibility with the env vars, so I did not want to live with that.
Aside from that, after I added a custom api.php I ran into the problem, that the custom auth file was not loaded, because the CoreServiceProvider did not read and include files from the custom folder.
The solution:
The first thing I did was add an if to the CoreServiceProvider to read a class from the custom auth folder if there would be a custom auth class and the class was not yet known.
secondly, I updated the Schema creation process.
To get a bit deeper on that. I wanted to change the settings for the schema according to the used env vars. So I added an env var to activate a custom context DIRECTUS_USE_CUSTOM_CONTEXT
if that is activated, the workflow works as following. It searches through the env vars and looks for DIRECTUS_CUSTOM_* variables. Those variables should contain informations on the fields to be added to the schema. Afterwards, the Schema will be enhanced and the enhanced schema will be returned to the algorithm reading the env vars into the config container to be used within directus