search

romainbessugesmeusy / netlify-plugin-auth0-patch-urls

A Netlify Build plugin that makes Auth0 works with deploy previews
MIT License
7 stars 3 forks source link

Feature: Build plugin inputs over env vars #7

Open alexrussell opened 4 years ago

alexrussell commented 4 years ago

The package uses env vars for the plugin's config. I admit this gives a lot of flexibility (specifically to be able to specify different Auth0 tenants/clients per-env) but is there anything in using inputs for certain parts of the config that are likely to be common (e.g. the callback and logout URLs)? Or do you not like this because it means that the "config" for the plugin gets split over two areas?

Being as plugins are defined in the netlify.toml file, I imagine we can set the plugins (and thus the inputs) on a per-env basis anyway (not tested), so actually we could move all the config to build plugin inputs, right?

Edit: At least one benefit of using inputs over env vars is that you get "validation" for free: you can say what's required and you can set defaults. No type/boundary validation however. Still better than nothing and having to roll your own.

Edit 2: The only thing I don't love about using inputs is that it means we can't keep the management client secret out of the code (with env vars we can set it up in Netlify's own environment vars in the build settings, but with inputs we have to add it into netlify.toml). I'm not sure if this really bothers me, but it's something worth thinking about.

romainbessugesmeusy commented 4 years ago

Since we'll probably use wildcards in the Auth0 UI, the only ENV variables left will be client IDs and client secrets for both apps... And I really don't see it as a good idea to have them in the .toml (it's a file that needs to be versioned)

romainbessugesmeusy commented 4 years ago

After taking a closer look, there could be Inputs for AUTH0_DOMAIN, AUTH0_CLIENT_ID, AUTH0_MANAGEMENT_CLIENT_ID and an Env var for AUTH0_MANAGEMENT_CLIENT_SECRET

tnovau commented 4 years ago

Since we'll probably use wildcards in the Auth0 UI, the only ENV variables left will be client IDs and client secrets for both apps... And I really don't see it as a good idea to have them in the .toml (it's a file that needs to be versioned)

I agree, also in OSS projects if you have them in .toml, that parameters will be visible to all.

alexrussell commented 4 years ago

After taking a closer look, there could be Inputs for AUTH0_DOMAIN, AUTH0_CLIENT_ID, AUTH0_MANAGEMENT_CLIENT_ID and an Env var for AUTH0_MANAGEMENT_CLIENT_SECRET

Yeah this is exactly how I've ended up implementing it in my fork of this repo.

Context-dependent config for input in the netlify.toml and secret being the name of an env var which is then looked up. Works nicely.