API token storage in blocks. Passport.js?

Holly,

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

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?

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…

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.

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.