Some scripts require sensitive input such as HTTP API access tokens. Depending on how the base is shared, it may not be appropriate to store this input in the scripts themselves. In these cases, it may be preferable to prompt the user with each execution.
Currently, the input.text function renders a generic HTML text input. For situations like these, it would be nice to present a password input. This would help protect users from shoulder surfing.
The CSO would string us all up for doing ANY of these things, but consider abstracting the access tokens well away from the script block and silently match up the user’s session ID with accessibility to any given base. You could also create a translation table in the script and encode the base IDs as base64 strings. Only during run-time would the keys be decoded. Most users would really struggle to get the actual keys from base64 strings.
One must ask, though, -
If a block has explicit read/write authority over the base itself, why would a script block need an API key? Unless, of course, it’s accessing other bases.
The CSO would string us all up for doing ANY of these things, but consider abstracting the access tokens well away from the script block and silently match up the user’s session ID with accessibility to any given base. You could also create a translation table in the script and encode the base IDs as base64 strings. Only during run-time would the keys be decoded. Most users would really struggle to get the actual keys from base64 strings.
One must ask, though, -
If a block has explicit read/write authority over the base itself, why would a script block need an API key? Unless, of course, it’s accessing other bases.
@bill.french Yup, or if it’s accessing web services outside of Airtable
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.