Environment variables for settings

[stephen-kainos]

What's your opinion on using their environment variables or WP constants to set the client_id and client_secret? This would make it easier to split out development and production environments.

[psignoret]

(Apologies for the delay, I'm still catching up on issues.)

Can you elaborate a bit more on how you would propose this be used? What would the dev/prod environments look like?

[StoneWaves]

We have various dynamic development environments that run multiple URL's (*.env.example.com) but share a DB, this would be an amazing feature to have if it's possible to implement.

[bradkovach]

@psignoret the easiest way to get this handled would be to use a wp-config.php constant to change the option key that's used when AADSSO_Settings::init is called.

Something like AADSSO_OPTION_KEY would allow multiple configs to live in the same DB.

Or maybe something a little more in-depth, allowing for automated deployments by pivoting back to the config JSON for advanced scenarios.

AADSSO_CONFIG_TYPE could be defined in wp-config.php and then a few values could be used: DB (default), JSON, ENV, or a super user could define their own (see below)

AADSSO_CONFIG_SRC could be defined in wp-config.php to further configure according to AADSSO_CONFIG_TYPE.

Here are some examples of how that might work:

AADSSO_CONFIG_TYPE	AAD_CONFIG_SRC	Notes
DB	aadsso_settings	Could be used to override the WordPress options table key, or leave blank for aadsso_settings
JSON	/path/to/aadsso_settings.json	Absolute path to the JSON config file.
ENV	AADSSO_SETTINGS	Environment variable that should contain a serialized configuration.

Nice To Have

• Make the AADSSO_Settings class abstract, and put its existing functionality into into AADSSO_Settings_DB. Create the AADSSO_Settings_JSON, and AADSSO_Settings_ENV to separate these specific configuration schemes.
• These configuration classes should have a hook or a function that is called to provide settings fields for inclusion on the settings page (if any).
• Implement templated class instantiation so that somebody could extend AADSSO_Settings on their own to build their own settings class (as a plugin separate from AADSSO Core).

// somewhere.php
function get_configuration() {
    $config_src = is_defined('AADSSO_CONFIG_SRC') && is_defined('AADSSO_CONFIG_TYPE')
        ? AADSSO_CONFIG_SRC 
        : ''; // or null?

    $config_class = 'AADSSO_Settings_' + AADSSO_CONFIG_TYPE;
    if(
           ! class_exists( $config_class ) 
        || ! is_subclass_of( $config_class, 'AADSSO_Settings' )
    ) {
        $config_class = 'AADSSO_Settings_DB';
    }

    // The $config_class constructor should be prepared to handle $config_src as an empty string (or null) to trigger a default value
    return new $config_class( $config_src );
)

Assumptions

• We provide no configuration GUI for configuration types other than DB. We should, however, support overriding the settings form fields
• The absence of AADSSO_CONFIG_TYPE will cause AAD_CONFIG_SRC to be ignored--use them both, or use none of them.
• Invalid values should fallback to a sane default (DB with aadsso_settings)
• Issues with the singleton instantiation currently handled by AADSSO::instance() may come up, and might require some re-engineering.
• No changes will be made to the DB schema at this time.
• No namespaces for custom config classes.
• Configuration errors are inevitable, so returning/throwing WP_Error from a custom config class should be shown to the administrator in a sane format.

Benefits

• Provides a robust hook for advanced users to create configuration systems that work for their deployment process.
• Non-DB configurations could provide a performance boost for high-login-volume sites.
• Decoupled configuration classes can be unit tested.
• Separating concerns is always a good thing.

To be honest, this would be a welcome addition for many users, and seems like it would be fun to implement. Since this plugin is inherently for advanced users, we shouldn't be afraid of adding deep plugability/hookability to really customize configuration, since GPL already provides no warranty or liability. Let me know if you need clarification on any of my ideas, or if something is a major no-go based on what I've described.

I'm really happy to see this plugin getting used so widely, and in so many ways. Next stop: Version 1.0 in WordPress plugin directory? 😉

Happy Holidays, everyone! 🎄 🕎 🎅 :-)

[stephen-kainos]

Exactly what I’m looking for Brad!