Page 1 of 1
Creating a login form
Posted: Thu Jun 18, 2020 6:21 am
Pardon my newbie-ness, my colleague and I are trying to create an asset tracking app for our company. I'm looking for examples of setting up the login screen. Nearly every tutorial I find is the same: They create a database in MySQL, create a users table in MySQL, use the MySQL root account to connect to the DB, compare the username/password entered in the text boxes to the username/password in the newly created users table. Then any further transactions are all completed by the root account (or some other account they designate).
Fine if they want to do it that way, but I don't like that. Instead of creating a user table and adding users to it by their own registration, only a limited number of people will be using this app. We have already created their accounts at the DBMS level, so their accounts are in the mysql.user table. The proper permissions of the tables in our app have been granted to those users. I would like our login form to work so that the username/password entered in the textboxes will attempt to connect to MySQL. If an account has already been created for them in MySql, then they will be free to use the app. Any transactions will not be done through a single account, they will be done by the actual MySql user account of the person being logged in. Is this way just not a good best practice? Just asking because I can't seem to find any examples of it being done this way.
Re: Creating a login form
Posted: Thu Jun 18, 2020 11:19 am
This is possible; but as you've guessed, it's not commonly accepted practice when building a web application.
From a security point of view, this kind of direct access to the database through the internet increases the vulnerability of your app - and worse, your database itself - to attackers.
From a development point of view, it reduces your expansion options as you won't have the fine grained control you have if you build your own account model. For example; suppose you want to update your app so that certain users can make or withdraw a request to use an asset but cannot approve it, or can only view certain assets. You can probably get around this with permissions assigned to stored procedures, but you will start bumping up against the limits of what people expect to do with a database.
From a business advantage point of view, you're going against the grain of the usual development process and won't be able to benefit from existing processes. You're already seeing an example of this in that you can't find any resources telling you how to do what you're attempting. If you're just starting out at developing this kind of system, going with convention gives you a massive head start.
Depending on how straightforward your app is, I'd even be tempted to look at a framework to take care of the broad strokes of your system. Laravel for example can create an authentication system with a single command, leaving you to tweak your preferences and get on with solving the meat of your problem. You may not learn as much about PHP, but you'll get something useful much faster.