Closed nelsonic closed 2 years ago
Basically we can avoid hard-coding the auth_url
in the router.ex
of the "consumer" app:
Because the URL would be in the AUTH_API_KEY
environment variable. 💭
Adding the redirect url in the environment variable should work. I don't find it to bothering to define the url in the plug config, I was using it to test redirection to other auth applications while developing/testing but I don't mind to switch to a full environment variable configuration.
Like you said there will be a bit of refactoring to do, not so much on auth_plug
where we just need to extract the url once I think but mostly on auth
where we need to make sure we don't break the way we get the client id and client secret.
OK. let's roll this Developer Experience improvement into the "V2" update. 💭
To give you an idea: the project I've been working on these last few months has 27 environment variables. (and even more secrets stored in AWS Secrets Manager ... 🙄) It's an outlier because there are many 3rd party services . But I think it could easily have been reduced to 2 environment variables with a little bit of forethought which would have significantly reduced Engineer onboarding time.
As for the environment variables required to get the auth_plug
working ... My goal is to get it down to one.
That way when people run the dwyl/app
on their localhost
they can get setup in less than a minute and only have 1 thing they need to configure/set.
Thus minimising the friction/barrier to adoption & contribution.
I know some people will consider this "premature optimisation" to be thinking about the onboarding experience for new developers when our App isn't even built yet! But if the whole point of our App is to never waste people's time we need to be conscious of these tiny details at every step.
I'm adding the auth_url on the app show page:
<%= #{apikey.client_id}/#{apikey.client_secret}/#{auth_url} %>
However using the "/" character to seperate the different parts of the key might not work nicely with the url (ie https://...). I'm thinking of using "-" instead
<%= #{apikey.client_id}/#{apikey.client_secret}-#{auth_url} %>
@SimonLab yeah, was considering using the |
(vertical bar or "pipe" character https://en.wikipedia.org/wiki/Vertical_bar ) because it is seldom used in URLs. Also the auth_url
is just the base URL so it should never contain a |
(or at least we won't ever use it). 💭
sounds good, I don't mind to change "-" to "|". Or we could create an environment variable to configure this character in the app :wink:
There is however an issue in the .env file when we source them:
sh bash: https://dwylauth.herokuapp.com: No such file or directory
So it might not be the best character to use
@SimonLab i wasn’t going to use a fully qualified url (with the https:// ) as the protocol is just clutter. We will always connect over HTTPS so it will be omitted from the environment variable.
"https://" removed with https://github.com/dwyl/auth/pull/163/commits/01b19c2d02f332fb1ec0cd7ef6b4c2be703e6ce4
Thanks Simon! 🎉
The auth_url has been added to the api key with https://github.com/dwyl/auth/pull/163
While going through the steps of setting up a "dev" version of this app on Heroku so that we can have Review Apps https://github.com/dwyl/auth/issues/161, it occurred to me that Google includes a URL in their
GOOGLE_CLIENT_ID
... 🤯https://github.com/dwyl/auth/blob/165571db283c467818673d85ffb345c171bd959a/.env_sample#L6
e.g:
Note: Just an example for illustration. Not a real/valid key. 🔑
We could make the setup of
auth_plug
even easier because theAUTH_API_KEY
could contain theauth_url
and thus the single environment variable becomes all that is needed for configuration!This would require a fair amount of refactoring (2-3h with tests), but I think it's probably worth it! 💭
@SimonLab Thoughts? 💭