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.
It is option 1. I’d like to just attempt to do this.
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.
Your user portal project seems like exactly the sort of thing I’d like to do.
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 -
I’m a little confused as to how I can search through an Airtable database to find a username.
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.
I think what I’ll do is use the queryFilter to find a username, get the hashed password associated with that username, and compare it to the password inputted.
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.
Try reading the web article that I linked to. It will give you a lot of background info and things to think about. Plus it includes links to the actual code.
Only trouble is, is that I am using PHP, not JavaScript. I decided it’s safer not to use the JS API, I have absolutely no clue how to use JavaScript.
The article is still a good place to start.
I wrote my code in PHP. I only used JavaScript in the client.
Fair enough. So far, I’ve sort of written my own API, for my needs.
Why do you think the JS API isn’t safe?
If you want to write a web app with any client side interactivity, you’re going to have to learn JavaScript. If you want to use the Airtable Scripting Block, you’re also going to need JavaScript.
If you already know PHP, learning JavaScript is easy. (But I don’t recommend trying to learn both languages at the same time.)
No, as in, I decided to ‘play it safe’. I didn’t mean that it is not secure.
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. 
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.
This will help me in my research,
thank you.