API token storage in blocks. Passport.js?

[Holly_Gronau]

I am attempting to log my air table users into the Sanity.io using API token for authentication but I can’t find a setting to store the token safely in airtable. Do I need to build passport.js with third party authentication or am I missing something?

[Bill_French]

Holly,

I think what you need is this - I have not played with this yet, but it seems like the right approach.

New beta: script settings Scripting app

Hi everyone! We’re excited to announce a new beta feature for the scripting block: script settings! With script settings, you can define settings for your script: a title, description, and settings items (table, field, view, text, number, and select). From your definition, we render a settings UI. Users of your script can update the settings and run the script without needing to modify the code. You can sign up for the beta via this form. You’ll only be able to use script settings if you’ve sig…

[Holly_Gronau]

What I need is a way to store a bot Authorization: Bearer so my users that use my custom block can log into the data set and update this data using airtable. I added this beta but it looks like it just running JS inside the airtable itself vs. custom blocks? Or am I miss understanding?

[Bill_French]

Holly_Gronau:

so my users that use my custom block

Yeah, that’s a key piece of the puzzle. I did not assume you were building a custom block.

The way we have handled this is to create an authentication server (or use an open source platform like KeyCloak) to arbitrate access. But, in a custom block environment you are able to create something that should avoid this pattern, right?

If so, this about does it…

[Holly_Gronau]

I am not really sure with the custom blocks. It’s new to me I am still wrapping my head around it. Usually we are very careful with our API access and run it only in .env adding that information to a platform like Netlify or Heroku etc is easy they have made provisions for this without the need to use a proxy. The dataset I need access to is our own which runs live code online so it’s still risky to leave an open key in airtable. It’s more of a risk than I would like to take. I thought about using third party authentication and running passport.js but we are not set up at an enterprise level to use third party authentication.

Thank you for the example. I appreciate it. I can look into running a server in the custom blocks too.

[Bill_French]

Holly_Gronau:

so it’s still risky to leave an open key in airtable. It’s more of a risk than I would like to take.

Indeed. That’s why I suggested the opposite in my examples.

In a custom block (as far as I know), you control the environment no different than you would in a Heroku deployment. I would escalate this to Airtable support to get perfect clarity if you fear that the custom block framework in React is unable to support your security requirements.