Closed nilvon9wo closed 1 year ago
Pretty sure the latest version already works, you can see this issue here where the developer addresses it: https://github.com/ngocnicholas/airtable.net/issues/63
I read #62 and #63.... I don't find these texts entirely convincing. Yes, #62 does mention someone got the solution work with a "personal access token" and I'm not clear whether those have the 2024 February cutoff, but the new authentication method is using OAuth and if OAuth is done correctly, there should not be a long-lived token.
Instead, there should be a process where a client id and a client secret are periodically sent to a token server to get a new token which is typically very short lived.
To be honest, I'm still trying to figure out how and even if AirTable's OAuth is working. If I understand correctly, for their process even before we call their token server, we need to call an authentication server and we need to include some "code" which I'm having trouble obtaining.
Perhaps if I were able to get the OAuth JWT token, I would be able to pass it in in place of either the API key or the personal access token, but even if this works, I would consider that an incomplete solution since each developer would need to rewrite for himself/herself the process of getting the JWT. Moreover, the process of collecting the JWT token should be integrated into the process of calling AirTable so the solution will efficiently reuse the JWT or fetch a new one as necessary.
Yes, https://github.com/ngocnicholas/airtable.net/issues/62 does mention someone got the solution work with a "personal access token" and I'm not clear whether those have the 2024 February cutoff
According to the API Key deprecation notice, Personal Access Tokens and Oauth are both recommended replacements for the deprecated API keys.
As my use case feels entirely impersonal to me and most comparable integrations, I've done have used OAuth, I would have expected OAuth to be the correct replacement for our use case.
However, I've been in touch with AirTable support and they also seem to be suggesting we should use PAT. This seems counter-intuitive and causes me to doubt AirTable's security model, but I won't pretend to be a security guru.
If it is the case that PAT is correct for us, or at least the only AirTable supported option for our use case, I guess for the moment we won't need OAuth, but I expect at some point we may need to revisit this when someone with more authority than me tells AirTable they are doing things wrong.
It sounds like you're describing an issue with the underlying Airtable API, not with this Airtable.net API client, so I'm closing this issue. Please reopen if I'm misunderstanding.
I recently received the following email from Airtable:
... So far as I can tell, this package only supports legacy Airtable API Keys.