Hard-Coded Personal Access Tokens

I’m very new to development, so forgive me if these are silly/stupid questions.

Will Airtable accept extensions that have hard-coded Personal Access Tokens? I know in their ‘Polishing your Extension’ document, they state how they don’t like it.

What is the workaround?

I would like the extension to be able to refer to data from another airtable base. This other airtable base is read-only and viewable by anyone, and I don’t much care about the read/write personal access tokens being public.

Would storing it as an environment variable be a good workaround? Or is a server-side proxy really the only way to securely handle personal access tokens and api calls between airtable bases?

Thank you for any help you can offer!

Are you hoping to submit the extension to the Marketplace? If so, I highly recommend not hard-coding any credentials. Actually, I recommend not hard-coding any credentials, no matter how you plan on distributing the extension. It is hard to predict the future, and even though we don’t think things will change in 2-5+ years, things have a way of changing anyway. You don’t want to have to revisit your code just because of a hardcoded PAT. What if you accidentally delete that PAT and cannot get it back?

Deciding where to store credentials can be tricky. I believe that that if you want to store credentials from one instance of the extension and have it available to all users of the extension, wherever they may be, using GlobalConfig is the most straightforward method.

You can store credentials on your own server if you are comfortable setting all of that up. Of course, you would still need to have a secure method for your extension to authenticate with your server.

While I can understand not caring if a read-only PAT is exposed to the public, I have a harder time being blasé about a PAT with write access.