-
-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow binding to environment variables #1859
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
@@ -363,10 +363,10 @@ function QueryEditor({ | |||
() => ({ | |||
parameters: previewParams, | |||
process: { | |||
env, | |||
env: Object.fromEntries(envVarNames.map((varName) => [varName, '<SECRET>'])), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, we're evaluating some bindings on the client side...
Then I guess it isn't possible to only send the variable names?
😕 This is not great
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it's not secure this way? I thought it only uses the real environment values if it runs server-side :/ Shouldn't that be possible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes client-side it won't use the real values in this case, yeah...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can show <SECRET>
and use the real values in the client anyway if that's still safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can do either one of those:
- Send the whole env like you did before and let it be
- Rethink how to use secrets in rest datasource and instead offer a new type of binding, next to javascript expression, allow binding directly to an environment variable through a dropdown
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we can go with the first option "Send the whole env like you did before and let it be".
But let me know if you think the second one is better for any reason and it would not be that much extra work anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some arguments I can think of that would be in favor for the second solution:
- It's easier for us to detect which environment variables an app expects to be run under. That allows us to warn on any missing ones, e.g. when a user checks out an app for the first time. It could somewhat be extracted from the javascript bindings by regex, or static analysis, but it wouldn't be a foolproof solution.
- We could more fine grained specify where exactly we want this to be used. e.g. only in authentication/headers
- Thinking long term, suppose we decide that whatever we came up with in this PR was a mistake, we can migrate from
$env: MY_VAR
to$jsExpression: 'process.env.MY_var'
and guarantee no breaking change, we can't do that on the inverse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair points, ok I'll change it to be a new type of binding, having it as $env
sounds consistent with the other types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. I'd change a few things:
-
avoid the layout shift when switching tabs in the binding editor
Screen.Recording.2023-05-14.at.12.11.39.mov
-
Make it a free input with autocomplete. We can give an indication when we don't find the environment variable in the env file, but I feel like we should allow input. As a follow up we can prompt the user for a value if we don't find it in the env file and add it automatically
-
Update the
rest-basic
test with some checks for environment variables.
Additionally we should update the HTTP query docs. This can be done separately as well if you want
@@ -301,6 +308,7 @@ export const META = { | |||
definitions: { | |||
Json: jsonSchema, | |||
JsExpressionBinding: jsExpressionBindingSchema, | |||
EnvBinding: envBindingSchema, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a note, but after beta we will have to think about a migration strategy, because this is not backwards compatible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it's not a breaking change, just a new type of binding, right? Why would it break with previous versions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An app created with this schema won't work in older Toolpad versions. Older Toolpad versions don't know what $env
means
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I thought we only needed to make to make old schemas be able to migrate to newer versions...
If we have backwards compatibility like this I guess we will need to migrate, yep.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The general idea would be:
- old schema + new toolpad => we should be able to internally migrate and display the app + give option for user to migrate files to new version, or do it automatically
- new schema + old toolpad => either all features of the schema are supported in Toolpad, or otherwise we need to tell the user "This app as created in newer Toolpad, please upgrade Toolpad to version X if you want to run/edit this application"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first thought the 2nd option (showing the user a message) seems more sane to me and not that unusual?
But we can try the first one if it's not that hard, also depending on how common it would be for users to try to use new schemas in old Toolpad versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also depending on how common it would be for users to try to use new schemas in old Toolpad versions.
This scenario could happen when people copy toolpad apps from one repo to another
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is great!
This should be very helpful! I'll resume work on some of the public apps that needed this feature. |
Ah, yes, awesome, we can move more apps https://github.com/mui/mui-private/issues/267. It's different than #1952 but would still solve the problem. |
Closes #1785
Allow binding HTTP request headers to environment variables (or any other property besides request headers, if we enable it to).
Includes tests and documentation.
Screen.Recording.2023-05-17.at.19.07.14.mov