Trigger Argyle Link #6
Conversation
allthesignals
commented
Apr 25, 2024
allthesignals
commented
- Generate Argyle userToken on load; API key is managed in .env.local
- Load Argyle Link javascript: there is no ES6 module for this. The code here wraps Argyle with a Promise by loading it into a script tag and resolving the promise when it's loaded.
- Provide support for hoisting the userToken into the head's meta tag
- CSP updates
|
|
||
| def index | ||
| res = Net::HTTP.post(URI.parse(USER_TOKEN_ENDPOINT), "", {"Authorization" => "Basic #{ENV['ARGYLE_API_TOKEN']}"}) |
There was a problem hiding this comment.
Keeping this here until we have a proper Argyle service
There was a problem hiding this comment.
I see - so we exchange the API token for a user token. The user token seems like a great thing to store in the database under than flow object we were talking about.
There was a problem hiding this comment.
Yeah! I think the userToken expires, but we do get a user id for "faster token renewal" (not sure what that really means). So, we'd likely store the id in the database, store the ephemeral token in a cookie.
Argyle Link has a nice little callback for when the token is expired. We could have that supplied with a renewal cal that includes the long-living "user id."....
| // general event for when anything happens in the flow | ||
| onArgyleEvent() { | ||
| this.element.submit(); | ||
| } |
There was a problem hiding this comment.
This is just a catchall event to move us along in the part of the flow we control
| policy.font_src :self, "https://*.cloudinary.com" | ||
| policy.form_action :self | ||
| policy.frame_ancestors :none | ||
| policy.img_src :self, :data, "https://www.google-analytics.com" | ||
| policy.img_src :self, :data, "https://*.cloudinary.com", "http://*.cloudinary.com", "https://www.google-analytics.com" | ||
| policy.object_src :none | ||
| policy.script_src :self, "https://js-agent.newrelic.com", "https://*.nr-data.net", "https://dap.digitalgov.gov", "https://www.google-analytics.com" | ||
| policy.connect_src :self, "https://*.nr-data.net", "https://dap.digitalgov.gov", "https://www.google-analytics.com" | ||
| policy.script_src :self, "https://*.argyle.com", "https://js-agent.newrelic.com", "https://*.nr-data.net", "https://dap.digitalgov.gov", "https://www.google-analytics.com" | ||
| policy.connect_src :self, "https://*.argyle.com", "https://get.geojs.io", "https://*.nr-data.net", "https://dap.digitalgov.gov", "https://www.google-analytics.com" | ||
| policy.worker_src :self, "blob:" |
There was a problem hiding this comment.
I could see an "Argyle plugin" including some kind of CSP configuration mixin so that this is managed more neatly.
There was a problem hiding this comment.
Interesting, yeah, I wonder how this is maintained in large apps with a lot of dependencies. Do large apps really need to incorporate all of their dependency's CSP entries like this?
There was a problem hiding this comment.
I'm not really sure... Login uses their config (env variable) store to manage some of it: https://github.com/18F/identity-idp/blob/main/config/initializers/content_security_policy.rb
Were you expecting the dependencies to be able to configure CSP stuff themselves? I could see us using maybe plugins to manage some of the provider-specific initialization?
| @@ -8,3 +8,4 @@ | |||
|
|
|||
| # SHOW_DEMO_BANNER controls whether to show the TEST SITE banner in Rails.env.development | |||
| SHOW_DEMO_BANNER=false | |||
| ARGYLE_API_TOKEN= | |||
There was a problem hiding this comment.
A pattern I've seen at other companies is to put the .env.local file with all the actual secrets in it, into a shared secret store like 1password. Engineers would copy it from there whenever a new secret is added. Do you know if that's how we generally do things here or if there's a better way?
There was a problem hiding this comment.
Sounds good! I think it's really up to the teams but we could survey some of the other engineers about good patterns for this.
Past projects I've seen have leveraged AWS' secrets storage feature. Login has a fairly complex environment variable validation system that could be nice if we find things become a bit sprawling. I see that being important for projects with lots of teams and lots of turnover. Want to prevent accidentally spilling secrets...
Your idea to use .env.local in 1pass seems fine for now...
|
|
||
| def index | ||
| res = Net::HTTP.post(URI.parse(USER_TOKEN_ENDPOINT), "", {"Authorization" => "Basic #{ENV['ARGYLE_API_TOKEN']}"}) | ||
|
|
||
| @userToken = JSON.parse(res.body)["user_token"] |
There was a problem hiding this comment.
style nit: Let's use snake_case for ruby variables. I can get rubocop linting soon so it will do it automatically.
There was a problem hiding this comment.
Yes! My b. I always do this when switching between JS and Ruby...
|
|
||
| def index | ||
| res = Net::HTTP.post(URI.parse(USER_TOKEN_ENDPOINT), "", {"Authorization" => "Basic #{ENV['ARGYLE_API_TOKEN']}"}) |
There was a problem hiding this comment.
I see - so we exchange the API token for a user token. The user token seems like a great thing to store in the database under than flow object we were talking about.
app/javascript/utilities/argyle.js
Outdated
| export function initializeArgyle(Argyle, userToken, callbacks) { | ||
| return Argyle.create({ | ||
| userToken, | ||
| sandbox: true, // Set to false for production environment. |
There was a problem hiding this comment.
Probably should make this an environment variable at some point. I wonder how we could get an environment variable into this JS file.
There was a problem hiding this comment.
Will do. Actually, I have an approach for that (yet another thing I cribbed from Login)...
The line here hoists the variable up to a meta tag.
Then this helper can read it.
It's a little dangerous because someone could accidentally share secrets to the end user, but this is how Login did it.
| policy.font_src :self, "https://*.cloudinary.com" | ||
| policy.form_action :self | ||
| policy.frame_ancestors :none | ||
| policy.img_src :self, :data, "https://www.google-analytics.com" | ||
| policy.img_src :self, :data, "https://*.cloudinary.com", "http://*.cloudinary.com", "https://www.google-analytics.com" | ||
| policy.object_src :none | ||
| policy.script_src :self, "https://js-agent.newrelic.com", "https://*.nr-data.net", "https://dap.digitalgov.gov", "https://www.google-analytics.com" | ||
| policy.connect_src :self, "https://*.nr-data.net", "https://dap.digitalgov.gov", "https://www.google-analytics.com" | ||
| policy.script_src :self, "https://*.argyle.com", "https://js-agent.newrelic.com", "https://*.nr-data.net", "https://dap.digitalgov.gov", "https://www.google-analytics.com" | ||
| policy.connect_src :self, "https://*.argyle.com", "https://get.geojs.io", "https://*.nr-data.net", "https://dap.digitalgov.gov", "https://www.google-analytics.com" | ||
| policy.worker_src :self, "blob:" |
There was a problem hiding this comment.
Interesting, yeah, I wonder how this is maintained in large apps with a lot of dependencies. Do large apps really need to incorporate all of their dependency's CSP entries like this?
