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?
Holly,
I think what you need is this - I have not played with this yet, but it seems like the right approach.
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?
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…
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.
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.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.