May 22, 2020 02:22 PM
Hey everybody! I’m starting development on a block for the hackathon – super exciting!
I’m going to need to store a unique token for each user, because I’m going to need to do some OAuth in my block.
I’m wondering the best approach to do this? I could store it in GlobalConfig, each token is accessible through the ID of the user, but I’m not sure about that. Any advice would be much appreciated!
I noticed this is done the demo for blocks, by storing the Twilio ID and Secret, so I’m curious how it’s done there
Solved! Go to Solution.
May 22, 2020 03:34 PM
Hi Alec, welcome!
Here’s the code from the demo video. In that case, I was hard-coding the API keys into my code.
In our other blocks, for example the Map block and the Send SMS, we prompt the user for their API key and store it in globalConfig
.
In these cases, we usually don’t store a token per user ID. The tokens are shared across all of the users who can access that block installation, which is nice because it means one person can set up the block in the base and then all of their base collaborators can use it.
May 22, 2020 02:35 PM
Hey Alec, which hackathon?
May 22, 2020 03:07 PM
May 22, 2020 03:34 PM
Hi Alec, welcome!
Here’s the code from the demo video. In that case, I was hard-coding the API keys into my code.
In our other blocks, for example the Map block and the Send SMS, we prompt the user for their API key and store it in globalConfig
.
In these cases, we usually don’t store a token per user ID. The tokens are shared across all of the users who can access that block installation, which is nice because it means one person can set up the block in the base and then all of their base collaborators can use it.
May 22, 2020 03:44 PM
Oh, I see! So it’s global across the collaborators in the base, not everyone who has installed your block?
May 22, 2020 03:53 PM
Yep that’s right! globalConfig is scoped to the block installation. A block can be installed multiple times in the same base or across different bases, and each installation has its own distinct globalConfig storage.
May 23, 2020 07:12 PM
Is it possible to do OAUTH with Airtable blocks ? What value are you providing for the return url after user grants access ?
May 23, 2020 10:05 PM
+1 on the OAuth ask. :slightly_smiling_face: Ideally, my block would call a service I’m hosting and, from that service, one could update the original AirTable with the REST API. A bi-directional sync of sorts.
I can ask the user for their AirTable API token inside my block and pass a version of that along to my service, but that seems like it’d be frowned upon and less ideal than getting an OAuth token. Maybe asking for it in the block is ok for a MVP?
Any other ideas or feedback is welcome!
May 26, 2020 09:33 PM
I tried OAUTH with a pop up flow. But, it doesn’t work either because browsers don’t allow an iframe(custom blocks are in ifraMes) to communicate with another iframe(OAUTh popup).
May 27, 2020 07:20 AM
+1 for Oauth2 Authorization Flow support, or t least “throwaway tokens” for specific Blocks, that would increase adoption by security-savvy users