Ok so I know that this would be fairly complex, and may not be possible, but if it is, how would I go about making a login system using Airtable. I am trying to see if I can use Airtable as the backend database to something, and I’d like to try and refrain from using an SQL database, if possible. Of course, if completely necessary, I am completely comfortable doing so.
Any help is appreciated.
Two things come to mind with this statement - please tell me which you are inferring:
If it’s #1, I don’t recommend it, but I also don’t know anything about your grander objectives. If it’s #2, there are many examples where developers have abstracted Airtable data away from the Airtable app and provided fairly good security features. Stacker.app comes to mind as one to look at.
Are you looking for something like this article about creating a user database?
Keep in mind, that in addition to the security issues for storing user credentials in Airtable, you also have to figure out how to send those credentials back and forth securely, and how to use those credentials securely in the rest of your website.
One of my first projects when I was learning how to code was creating a user portal website with an Airtable backend. In that version, I stored user credentials in Airtable. So, yes, it is possible, even for someone new to coding, but it is also a lot of work.
Okay, #1 it is. This is possible, but it might not be ideal from a security perspective (and I’m no security expert either). In any case -
Your web app could do this in a number of ways; here’s one…
You could also perform a direct queryFilter on the table via the API requesting only user/pw that matches.
In my personal experience, building a user portal was considerably more difficult than Bill’s three steps imply. Probably by several orders of magnitude.
Plus, there’s everything you have to do once you move past the login page …
However, you are probably starting with more coding knowledge than I had, so it may be easier for you.
Why do you think the JS API isn’t safe?
Just to be clear - “Bill’s” three steps represent the broader psuedo-process of a login page, not a portal, and certainly not trivial. In fact, I recommended it not be the recommended approach so the implication I made was don’t do it. :winking_face:
Yep - that works. Just be clear that if a user struggles to remember a password, this multiplies the request-responses needed to get someone logged in. This is typically not a big issue unless you have dozens of people logging in at about the same time and if so, you’ll likely have to consider the rate limiting on the Airtable API. The first approach tends to avoid this.
This is one of the tradeoffs in web app development - do you make a single aggregate call to set the stage for unanticipated follow-on data needs in the client? Or, do you use multiple HTTP POST sessions for each process? I tend to tilt toward caching data forward to meet the next likely data need.
Airtable as a back end for a user portal definitely has scalability issues.
However, for small projects and initial proof-of-concept designs, it can work very well. The ease in viewing and editing the data make it much easier to start with versus an SQL database that does’t have a pretty front end.
Once you have a working prototype, you can then move to an SQL database on your server if you need to.