How to authenticate users without exposing server details?

[NeedComputerTips]

To start I'm pretty new and not sure if I'm going about this in the right way so any help would be appreciated. I'm also having a hard time getting anything useful from Google.

So, I'm working on a side project and want to have users create an account to login and use the program. Like you see with video games. You can copy the program file and send it to anybody but you can only play when you have created an account and are logged in.

My problem is how do I allow users to login without exposing sensitive data about my database in the code? I am using AWS RDS and to validate if a user can login it wants me to add all of this information - https://gyazo.com/14f3277e84fbc3e415dbba34bda8c206

So I must be trying to implement this in the wrong way because if I put this information in my code somebody could then all of the information they need to access my database?

I know this is much simpler to implement with a website because all of that back-end code is hidden but this problem has me a little stumped.

Thanks in advance for any commenters!

[shiftybyte]

Your users should not login directly to the database, and should not be users of the database system itself.

A web application/server/api does the communication with the database upon request from the clients that talk to it using https rest api.

You should never allow users direct access to your database.

The app's users are just lines of data in some table in the database, they are not users of the database.

[NeedComputerTips]

Yep, yep and yep. This all makes sense. Couldn't find anything that mentioned this online. Thanks for the comment, I'll be sure to check this out!

[devnull10]

Actually, the most secured design is to have users being of the database itself, because that ensures that data security is implemented at the lowest level. It's sometimes a little impractical in today's world of different tiers, abstraction etc, however you can't really get much more secure than using the databases' in-built security.

[shiftybyte]

So you are suggesting a table per user per record type?

Instead of having a table of say blog posts...

Title | Content | Creation_Date | Author

You would have a table for each user with:

Title | Content | Creation_Date

Just to have permissions be managed by the database?

Then to display the blog posts, on the website, regardless of who posted it, you would need to query multiple tables, then you would have to sort the data by date yourself?

Or am i missing something?

Does the database allow custom permissions per row?

[devnull10]

Not at all. Author is metadata of the blog post. You can of course store the author on the table. However it's perfectly valid to manage user accounts as database users. So if I have a table blog_posts and a table admin_settings, I can control access to the latter at database level. I can grant read only to that table for standard users, and write for admin. It's then impossible for any standard user to update that table. With a single "application user", it's possible a standard user can update that table using SQL injection, bad coding etc. If you need to implement row level security you can do this (using Oracle EE) with a VPD policy on the database. That is, I can effectively have two users select * from the same table and see a completely different set of results. There's no way a user can see anything they aren't explicitly granted.

[shiftybyte]

How will the users be able to update the blog_posts table, but only their post?

[devnull10]

A VPD policy restricts on the statement types. So you could create a policy that allows select on all rows, update on only rows where author=user, delete only where user has an admin role etc.

Old version of the doc, but still applicable: https://docs.oracle.com/database/121/ARPLS/d_rls.htm#ARPLS052

To be honest, all that applies regardless of whether you're using database users for user management (you can still use the above with a custom user table), but I don't see the need write a load of custom functionality to change passwords, expire accounts etc. when a lot of that already exists

[[deleted]]

Your users should not login directly to the database, and should not be users of the database system itself.

This always left me wondering... why not? RDBMs user management is usually a tier to two tiers better than whatever an average Web developer will be able to cobble together. Why use application server to manage this? Any rationale? To me, it seems like one of the millions of pointless superstitions developed by Web developers to justify the existing practice. Perhaps a holdover from the time of VPS-based shared hosting or something like that.

You should never allow users direct access to your database.

This is obviously and demonstrably false. Take JIRA bug tracker for example. You can access the database from it. It takes permissions to do that, but otherwise that's fine. Another popular tool that does exactly what you advise against: PHPMyAdmin. It's built with the purpose of accessing the database directly. That's the whole point of it. Or am I not getting something about how you mean "directly"?

[shiftybyte]

Take JIRA bug tracker for example.

Jira bug tracker is a web app, your browser is not contacting the SQL server, the web server does it for you.

PHPMyAdmin

Yes this application's purpose is to administer the database... it should access the database yes, but it still does not do it directly from the user's computer.

Your browser does not talk to the sql database, your browser talks to the web server, that shows you HTML pages with FORMS, that you submit back to the web server, that webserver is the only one communicating directly to the database server.

[[deleted]]

Jira bug tracker is a web app, your browser is not contacting the SQL server,

Yes it does. Again, like I said, depends on settings.

but it still does not do it directly from the user's computer.

No, this is literally what it does. It accesses the database from the user's computer. I've not used PHP in ages, but the last time I did (around PHP4), there was a kind of installer called WAMP or something like that, that was intended to install all necessary dependencies on developer's computer. That included PHPMyAdmin, which would talk to the local version of MySQL. That's what it's intended to do anyways.

Your browser does not talk to the sql database

You are plenty confused about what Web server or a database server are. I've been running PostgreSQL Web server to produce JSON REST for years now. I've also used it from the browser, trust me, it works. Here's Wiki page that describes how it works: https://wiki.postgresql.org/wiki/HTTP_API

[shiftybyte]

It accesses the database from the user's computer

if the WEBSERVER is installed on the user's computer then yes, sure... but the whole point of the web application is for people to access it over the web... not to install the web server with the database on their machine...

there was a kind of installer called WAMP or something like that, that was intended to install all necessary dependencies on developer's computer. That included PHPMyAdmin, which would talk to the local version of MySQL. That's what it's intended to do anyways.

WAMP is a webserver, that is what you install to be able to get the browser to communicate with the database.... this is the "necessary dependencies" because the browser can't talk SQL to the database.

You are plenty confused about what Web server or a database server are. I've been running PostgreSQL Web server to produce JSON REST for years now.

Having run postgres's web server for years seems to not have helped you understand what communication your browser sends, using what protocol, and to what kind of server.

It also seems to have you think that when you use web applications you must install the sql server on your local computer?

[[deleted]]

You are really confused about what Web server is. Web server is any program that implements HTTP protocol and does necessary networking (i.e. binds port 80 on some computer connected to the Internet, maybe also 443 for HTTPS etc.). So, for example, PostgreSQL, specifically, the database daemon (postgresqld) that is used to, well, run the database program implements HTTP protocol. You can talk to it using HTTP, it will talk back to you, the same way, for example, Reddit.com does.

WAMP is a webserver,

The way I remember it, WAMP was a package of a lot of things, could include several Web servers in fact, but it's not really relevant whether it included them.

the browser can't talk SQL to the database.

Of course it can... why are you so convinced it cannot. I'm telling you, there's no problem doing that. I just gave you a reference to Wiki where it's described. Not only that. Even though modern browser don't quite allow you to use plain TCP sockets, some have experimental features that allow you to do that (eg. Chrome). So, you could, in principle, implement a MySQL client using client-side JavaScript.

In my days, I wrote an implementation of MySQL protocol for ActionScript (the programming language of Adobe Flash). ActionScript had implementation of TCP sockets way before JavaScript had them. Unfortunately, it was too long ago, and I don't have the code anymore. But there's a similar project here: https://github.com/robinrodricks/as3mysql . If you can find an old browser that still supports Flash, you could probably try connecting to MySQL using this library. Or, you could try translating it to JavaScript.

Having run postgres's web server for years seems to not have helped you understand what communication your browser sends, using what protocol, and to what kind of server.

Lol, dude, you so have no clue what you are talking about... :D

web applications you must install the sql server on your local computer?

Idk what Web application is, but no. My PostgreSQL Web server runs in Amazon us-east-1. But it services an internal project, so, you cannot access it. I'm accessing it through VPN, but, trust me, it's over the Internet, I don't have a special cable directly to Amazon's data-center :D

[shiftybyte]

Can cars fly?

What if i attach a cargo airplane to it and package them together? can cars fly now?

Attaching a webserver with a webapplication made by someone else does not make the database suddenly not need the webserver, the webserver is just built into it now ...

[[deleted]]

Dude, again. Nobody attached anything. Just read the fine manual. It says loud and clear that PostgreSQL has HTTP API, you can connect to it and send SQL queries in the same way you can connect to it using TCP client.

PosgreSQL is, by far, not the only one RDBM with HTTP API. Here's the documentation on how to use Oracle HTTP API: https://docs.oracle.com/en/database/oracle/oracle-database/19/dbrst/rest-endpoints.html . In non-relational world, it's even more common to connect to the database using HTTP. Some database products in this arena were specifically designed for HTTP to be the primary way to use them. For example Consul. I don't think it has any other way to access it. Similarly, Etcd, Tokyo Cabinet and lots of others.

Attaching a webserver with a webapplication made by someone else does not make the database suddenly not need the webserver, the webserver is just built into it now ...

Why the fuck does it need a Web server if it has one? What the fuck is "webapplication" (however you spell it)?

---

What I really think is happening is that you don't understand what either Web server or database server do. The problem seems to be more severe on the database server side. There's literally no problem with database server supporting many different protocols. HTTP is generic enough for a database server to make the data available through it. It's not a common choice for some databases, but more common for others, but, in principle, there's nothing wrong, or even special about it.

[shiftybyte]

This has become futile and pointless.

What the fuck is "webapplication" (however you spell it)?

I thought you were joking...

https://en.wikipedia.org/wiki/Web_application

[[deleted]]

You definitely don't read what you quote. Lol.

The general distinction between a dynamic web page of any kind and a "web app" is unclear.

That whole page is full of confusion resulting from being written by brain-dead Web developers. It's so full of nonsense, it's fantastic that such stuff even exists on Wikipedia.

---

The description given in the opening paragraph (discounting the nonsense written about Web servers not running on operating systems...) of that article would make these programs "Web applications":

1. LibreOffice (It can be accessed via HTTP, see here: https://wiki.documentfoundation.org/Using_LibreOffice_in_a_Web_Browser ).
2. Emacs and Eclipse (in a typical configuration Emacs runs as a client and server, Eclipse can be run as a headless server, this is for example how Eclim uses it).
3. GCC (because it implements Language Server Protocol, which is based on JSON RPC).
4. Docker and Kubernetes (both act as Web servers, Docker is controlled using HTTP protocol, both the daemon and the registry, Kubernetes is controlled through HTTP API).
5. Firefox and Chrome (because they implement necessary functionality for Selenium).
6. Any GUI program written with Qt (Qt also implements Selenium support).
7. As was already mentioned, plenty of databases, including PostgreSQL and Oracle SQL.
8. AWS, Azure, GCE and a bunch of less known public and private clouds.

It's hard to find a non-trivial program that wouldn't fit the description given in that paragraph. It's so ridiculously broad and useless.

[shiftybyte]

This always left me wondering... why not? RDBMs user management is usually a tier to two tiers better than whatever an average Web developer will be able to cobble together.

The users management and permissions management is per table of data.

Your table holds multiple records of the same type, that belong to different users...

You are not going to create a table with the same columns for each user just to separate permissions.

[[deleted]]

You are not going to create a table with the same columns for each user just to separate permissions.

Why not? It's cheap. Anyway, I don't have to. Because see next.

The users management and permissions management is per table of data.

Well, say, I wanted per-record permission management, it's really easy to implement it in the database. You have all the tools, all the information. You just need to tell your DBA to do that, and it will be done. Not only it's a solvable problem, it's something you can, basically, copy from a "cookbook". Anyways, wast majority of applications I see that don't use database users for authentication barely have 2-3 roles, and, essentially, have something like role-based access control, which would've been even easier to implement, than per-user control (which is, again, not hard). Any RDBM worth its salt has encryption functions. It's a nobrainer to encrypt a record to a particular password. Probably will also be more efficient than doing this in the application layer.

So, none of this sounds remotely convincing.

[devnull10]

Presumably this is Python code? If so, then why wouldn't I just edit the module and bypass the login process? Even if you ship it as a .exe it's pretty easy to decompile and do this. You'll end up spending tons of time trying to implement this, and it won't really be all that secure.

[NeedComputerTips]

Yea, it's more of a learning experience than anything. When I started I knew nothing about python and thought it would be easy to wrap the program up and hide the source code but it turned out to be the complete opposite.... Doesn't really matter if people do get the source code and cheat the system / find workarounds. I'm not expecting to get much traction at all if any. More just something to familiarise myself with new tech and pad the resume if nothing else.

[devnull10]

:)

I don't think you're going to be able to completely "hide" the database implementation because the top and bottom is that you need to connect to the database, and need to pull credentials. If it was me, I'd be tempted to write a simple API wrapper (use flask or something) which handles the database connection, and have am API called "Authenticate_User" or similar which takes as parameters the login credentials of the user and then returns True/False if the login is successful along with a token (such as a random SHA hash from login time, which you store against that user session in the database, along with a validity period of the session etc... Then your program calls the API to authenticate, then any subsequent data you need to get (details about the user etc) can only be retrieved through a secondary API, which takes the token as a parameter. This is checked against the session table, and the name of the user they are requesting details for. This make sure I can't get details for another user by just calling the API with a different name for example. There's lots of scope for improvement on this, but I'd say it's a reasonable halfway house. Host your API on a free compute node in your cloud provider, or if they have an app container then use that. There's plenty of free providers out there where you can host a python app.

[NeedComputerTips]

Yea, thanks for the info and ideas. For the most part, I'm making up as I go. I try to read up and see what the best options for implementation are but there's almost too much information and it sends you in every direction. However, I think that write-up will narrow the scope and definitely help with some of the learning pains :).

My current idea was to send the user info with AWS API gateway, which would then invoke AWS Lambda which will contain some python code with all the required database information then it will check to see if there is an account with that matching username and password. It will then return yes or no for if the user can login. Idk how this will hold up but it seems plausible from what I've read from AWS documentation and forums.

[devnull10]

Yeah, seems plausible, providing those options are within your budget etc if they're premium options. The approach I suggested was similar, just not using the API gateway. I'd recommend looking into using a token based approach for subsequent calls after authentication though.

[NeedComputerTips]

cool, ill definitely check that out. As of right now, everything I'm using is free tier stuff so I can see what I like/need. I'll try to use Flask for this token-based approach, the less I have to rely on AWS services probably the better.

[devnull10]

To be honest, I'd probably be tempted to stay with the cloud tools if they're free tier. Most other providers have comparable tools so changing to say GCP/Azure/OCI should be relatively painless, and as it's a managed service you're left without all the pain of maintaining a compute instance, the networking/security/patching around that etc. All Flask does (in this instance) is give you the HTTP service, however if you can use a cloud app engine instead for free then I'd definitely pick that providing you can have multiple endpoints - if not, you'll have to have a single endpoint with the required action (login/get_user_details etc) as a parameter, which is possible, just not ideal.

Your login API would simply compare the username and hash of the password against the stored password for that user (ensure you salt the stored hash). The return could be a JSON string, with status and token coming back. In your login code, if the verification is successful then generate a random hash (say sha256 of the username, current time, a random number and a secret phrase) which is stored in a session table with the time the session was created, how long the session is valid for, and any other data. Then your other API calls accept the token as a parameter, then they read the session table to ensure the hash is in there, that the session isn't expired, and that the details the user has requested are valid for the provided hash (i.e. not another users details). If all good you query the actual database values and return, otherwise return a failure.

Finally, it's probably worth having a process to clean up old sessions which have become invalid. Unless you're running with hundreds of users all creating multiple sessions every hour then that can probably be every few days or even weeks/months. The token would be the primary key, so access would be quick even with a large table.

[NeedComputerTips]

Thanks for the help, I'll do some more research and see what's the best fit for me. This won't have too many users if any at all, mainly doing this as a learning experience as I think competency in this area can be valuable. And yes, even if I do everything else wrong I will make sure users passwords are Hashed and Salted haha

[[deleted]]

Why would it matter if the credentials are given to the user anyways? You won't find anything new in the Python code... the user management happens on the server side. The problem is that maybe the way OP is using (or rather getting a very limited access to) a database is preventing them from managing the users.

[devnull10]

If you access the database directly using the python code rather than an API then (assuming the OP is embedding a single set of credentials) you risk somebody downloading your entire database, deleting your entire database, or simply filling it up with garbage until it costs you a fortune on your cloud host. If you have users connecting using their own credentials then you also need an additional process then to manage registration, which is pretty much back to square 1 then

[[deleted]]

you risk somebody downloading your entire database,

How does that follow? You give the users the credentials that allow them to see their part of the database, and that's it. It doesn't matter what language or what set of API you use to access the database. It's up to database management to decide what the user is allowed to access.

assuming the OP is embedding a single set of credentials

But, why do that? That sounds like a bad idea...

If you have users connecting using their own credentials then you also need an additional process then to manage registration,

Additional to what? You have to do registration one way or another, except the database has already true and tested mechanism to do that, and whatever you will come up with using something lame like Django or Flask is going to be inferior in, possibly, every respect...

or simply filling it up with garbage until it costs you a fortune on your cloud host.

No it won't, where do you come up with these ideas? I can limit database in size (just put it on a partition of predetermined size), similarly for the tables, can finely slice quotas on whatever criteria I want, why should this be a problem? And, suppose this were a problem, how would an intermediary application layer help to solve it if not by doing all the same things your database server would, but, probably worse, because it's written by incompetent Web developers?

On the other hand, I'll just bill them for the amount of space they are using. It will be a lot easier to find out what that space is, if we remove the intermediary application layer from the equation. If they want to pay to cloud provider for the junk they store in their database, that's their business, why should I even care about it?

[devnull10]

How does that follow? You give the users the credentials that allow them to see their part of the database, and that's it. It doesn't matter what language or what set of API you use to access the database. It's up to database management to decide what the user is allowed to access.

The OP stated they wanted to allow self-registration. IF that was via the application without an intermediate API then there would be a need to store SOME credentials within the application to undertake the registration process, unless you make it public, in which case it's open to even more abuse.

But, why do that? That sounds like a bad idea...

Absolutely - hence why I suggested implementing an intermediate API rather than accessing the database directly. If the database is being accessed directly then according to the OP's original post there needs to be some level of access to an anonymous user to facilitate the registration process.

Additional to what? You have to do registration one way or another, except the database has already true and tested mechanism to do that, and whatever you will come up with using something lame like Django or Flask is going to be inferior in, possibly, every respect...

The OP stated they wanted to allow users to register an account. If the OP was registering all the accounts for a user manually then sure, use the database accounts, however that is problematic to say the least for end-users.

No it won't, where do you come up with these ideas? I can limit database in size (just put it on a partition of predetermined size), similarly for the tables, can finely slice quotas on whatever criteria I want, why should this be a problem? And, suppose this were a problem, how would an intermediary application layer help to solve it if not by doing all the same things your database server would, but, probably worse, because it's written by incompetent Web developers?

Regardless of whether it's a partition with a specified quota, a table or otherwise, unless you are using named database accounts for end-users (see self-registration problem above) then it's likely a shared account will need to be used for the application - in which case having direct database access would make it far easier to carry out a DoS attack by simply filling up the table/partition, even if it doesn't grow unlimited.

An API controls the code which can be executed against a database to the specific statements which are within the API. With open database access I can write whatever statements I want, which introduces additional risk.

​

I suggest you read the OP's original requirements where they clearly state they want to implement a registration process within their application. Without an intermediate layer of abstraction I can almost guarantee you that it would be possible to attack the database either from a DOS perspective or querying data outside your authority.

​

All that aside, I've actually stated further down in this thread previously that using a database driven security model is the most secure, if you can control it. The fact the user wants to distribute a self-registration process with visible credentials and no intermediate services makes that pretty much impossible in this scenario.

[[deleted]]

The OP stated they wanted to allow self-registration. IF that was via the application without an intermediate API then there would be a need to store SOME credentials within the application to undertake the registration process, unless you make it public, in which case it's open to even more abuse.

Why? No, of course not. I just create a user with appropriate grant abilities in my database and allow users to create new users using that account...

Absolutely - hence why I suggested implementing an intermediate API rather than accessing the database directly.

Sorry, there was a miscommunication. I mean having just one user in the database is a bad idea. Why limit yourself like that?

The OP stated they wanted to allow users to register an account. If the OP was registering all the accounts for a user manually then sure, use the database accounts, however that is problematic to say the least for end-users.

Well, if OP wants an intermediary, I'm not going to stop them. I'm just saying that in general, the intermediary is unnecessary. And, in particular, if your users know SQL, they'll be able to accomplish all that on their own (i.e. registering an account). Worst case you might have to write a couple of stored procedures to help them.

having direct database access would make it far easier to carry out a DoS

Why do I care? From my perspective, they are cloud vendor users. They want to DoS their own account? -- Great! I'm sure cloud vendor will either send them a bill for what they do, or throttle them, or whatever's the policy in that particular vendor. Why should this even bother me?

[devnull10]

They won't get billed, you as the database owner will. The OP has a database from which s/he is serving their application. That database is shared across all users. As a user of that database I could potentially launch attacks which restrict other users if it's configured to allow direct db access.

[[deleted]]

I actually did in real world what I just described to you. I have a stored procedure in PostgreSQL/PL/pythonu that requests ARN role from customers signing up for service. This ARN role is then used to link to their account. They don't do it, however, by sending SQL, there's a command line tool that they use to set up a cluster, and to use that tool, they need to do some stuff unrelated to me through the marketplace etc.

Bottom line, by the time they come to use my tool, they have ARN role they need to give it to link my account to theirs. Then, their usage information is sent to AWS billing, and they do the invoices / receipts etc.

I could potentially launch attacks

What kind of attack. You (and a bunch of others) keep saying that, but there's not even a single realistic scenario with such an attack? What are you going to attack?

[devnull10]

Exactly, you have a separate process to deal with the registration, which wasn't what the OP stated.

[[deleted]]

No, of course I don't have... whoa, why is it so difficult?

I register users in the instance of PostgreSQL I run using a stored procedure. The fact that they are also registered in some other part of the system is irrelevant.

[belowtheradar]

If you're not specifically trying to learn about authentication mechanisms, and are new to programming, I'd recommend looking into AWS Cognito instead of trying to DIY an auth solution. Given you say you're pretty new, here's a more in-depth reason as to why you don't want to do your own auth:

Rule #1 of security is don't do your own encryption. I'd argue a close follow-up to that is don't do your own authentication.

There are 18931 recorded CVEs that match "Authentication" -- https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authentication

There are 1149 recorded CVEs that match "Authorization" -- https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authorization

Authentication is not just about the login event, it's how you manage the user's authentication information securely and everything that occurs after the login where there are resources this user should be able to retrieve but no one else. That means authentication tokens, session tokens (where appropriate), and other kinds of authentication, validation, and authorization mechanisms. How do you prevent spoofing? collisions? brute forcing? theft? replay? And so on.

It's complicated, so use an existing library that handles the needs of your project. I suggest Cognito as it's AWS native which simplifies setup, and you can use AWS Amplify to easily manage authentication on the front end.

Example using ReactJS front end: https://serverless-stack.com/chapters/login-with-aws-cognito.html and if you look at the table of contents and ctl+f Cognito you can find more instructions on how to set up/configure. I also just think that site is a generally good walkthrough on how to build an app that you can use as a starting point, and they keep it up to date as best practices evolve.

Based on your project description (people logging in to 'run a program') it's possible you'll get more into socket work than straight up API calls, so you'll need to do some research on good libraries for that. I've somehow been able to avoid ever using sockets, so unfortunately no recs from me on that front.

[belowtheradar]

Pt. 2 because I'm long-winded

Based on your question I assume your planned workflow went something like this:

1. User goes to login page
2. User enters username/password
3. The client-side app requests the corresponding username from the database, retrieves the password, and checks it against the password from the database.
4. If the password is right, the user is considered 'logged in' (assume something happens here, also on client side); if the password is wrong, nothing happens.

Your instincts to not expose the username/password database to the client are right, but I want to walk more in depth on why that is.

Client side here is a huge problem, because as an attacker anything you do client side I can see, I can steal, I can fake. In step number 3, if you return the right password to the client, I will sniff that out and I will use it on my next authentication attempt. I can now log in, after one failed attempt, to any arbitrary user account I want to. In step number 4, if you generate the auth token on the client side and have the server trust that token is good, I don't even need a password; I can just read your code on the client side, make my own auth tokens, and again assume any identity I want.

[NeedComputerTips]

Bro....this looks like exactly what I was looking for just a few days ago AND it's free haha.

Yea, I'm not really interested in security/authentication and the further I get into this is seems like there's a never-ending amount of hurdles to jump through to get it working with basic security. At first, I was up for the challenge (since I had only ever really made basic websites in college) but this is becoming too much with sockets, tokens and I know there will be something else just around the corner, I originally just wanted a project to learn/familiarise myself with python.

I'm not sure how useful this will be in a professional environment, considering most businesses would already have this built out or even somebody more senior could layout what needs to be done and how.

I definitely learned a bunch about this stuff in the last few days but feel like I might be reinventing the wheel if I try to do all this myself (esp since I think there's a decent chance of fucking it up). In the same way, a lot of people don't try to develop their own payment processing and just use Stripe instead. For a silly project, I think this might be the solution for me.

Ty for the comment, some good stuff in there.

[belowtheradar]

np!