How Do I make a PHP login form without MYSQL or database? All the tutorials or google search results all have MYSQL or database in it with I find hard to learn and use. Can Someone make me a non-database login and signup that can actually do it and lead them to a dashboard that has the username written on it like,
WELCOME, INSERT USERNAME HERE
What makes you think that doing it without a database will be any easier?
Bearing in mind that everyone, and all the tutorials you saw choose to use a database for this for a reason.
Please remember this is not a free coding service. Members here will gladly help you with your code, but don’t expect to find folk to do it all for you.
Where do you propose storing user credentials if not in a database?
Text file, presumably.
Yes, a text file like CSV or similar is an alternative.
But to me it’s a more primitive, less functional (less useful) form of database.
When you want to start searching for things and making edits, you would wish you used a proper database in the first place.
Cutting corners does not always lead to an easier life. I say, bite the bullet and learn PDO. It will be more useful to you in the long run.
As droopsnoot mentions, files are pretty much your only alternative for a permanent storage of the user data. However, files open you up to potential security risks and implications that you would be better off avoiding by just using a database. These include…
All of these reasons is why databases are usually superior. They can be secured and protected by passwords and other applications, they are highly optimized to be efficient and they often have various locking mechanisms that work well with numerous users accessing it at the same time.
If, after all these reasons and comments by the other experts doesn’t sway you to just learn databases, at least do a few of the following with your file…
Make sure the file is not stored inside the web root of your site. PHP can reach files that are up and outside of its web directory.
Be sure that all passwords are hashed with a strong hashing algorithm (not something like MD5).
Design your application with the idea that the file may not always be available or accessible.
If the file gets over a few megabytes, I would then strongly recommend going to a database since that file will take longer and longer to read. PHP could even burn up a lot of memory and time trying to read it.
Good luck to you! 
Adding onto what Sam said, if you’re going to use a text based storage system, you’re going to have to understand a lot of things. You can’t just half guess what to do. There’s a lot of looping that goes into a system like this. A lot more logic would have to go into building such a system. Lastly, you would also have to take into consideration security. You have to keep those files safe from hackers.
Don’t the tutorials explain how to set up and use the database? Or do they assume prior knowledge of databases?
I would also advise that if there is a tutorial you had in mind, post here first for a review. It’s just that we see a lot of them teaching how to do it the wrong way. Anything using mysql, as opposed to mysqli or PDO, leave well alone. Anything using MD5 hashes, or even no hashing, stay away from it.
As Martyr2 says, you need to understand the considerations necessary to support multiple users of the data. You might be able to write something that manages the text file and all the online sessions communicate with that but that is probably more advanced than using a database that already has that.
There are some databases, especially SQLite and Microsoft Access, that also are not designed for multiple users.
Pretty much what everyone including myself is telling you here, just use a database. It’ll be so much easier for you.
If you insist on making such a system, you’ll need to know Linux or any *Nix system because majority of websites are hosted on them. You’ll have to know how permissions and file system works because you’ll want to know what the 3 numbers for file permissions represent. This will help prevent unauthorized access outside of the web root directory. You should also store your sensitive files above the web root as well with proper file permissions assigned.
Then you’ll want to learn about which is the best approach to storing data. Would you prefer CSV, JSON, or XML? JSON is the easier approach in this kind of environment. Then you’ll want to learn about how to read, write and access data from those files. And so much more.
So tl;dr?
Just use a database.
Using a database for this is exceedingly easy. All you will need to know how to do is make the database connection, and how to build and execute an INSERT query (in the signup form processing) and a SELECT query (in the login form processing.) The following shows the database specific logic, after you have detected if the form has been submitted, trimmed, and validated all the inputs, using the PDO extension -
Signup/insert query:
// if no errors, use the submitted data
if(empty($errors))
{
$sql = "INSERT INTO users (username, password) VALUES (?, ?)";
$stmt = $pdo->prepare($sql);
try { // a 'local' try/catch to handle a specific error type
$stmt->execute([
$post['username'],
password_hash($post['password'], PASSWORD_DEFAULT)
]);
} catch (PDOException $e) {
if($e->errorInfo[1] == 1062) // duplicate key error number
{
$errors['username'] = "Username is already in use.";
} else {
throw $e; // re-throw the pdoexception if not handled by this logic
}
}
}Login/select query:
// if no errors, use the submitted data
if(empty($errors))
{
$sql = "SELECT id, password from users WHERE username = ?";
$stmt = $pdo->prepare($sql);
$stmt->execute([
$post['username']
]);
if(!$row = $stmt->fetch())
{
// username was not found
$errors['login'] = "Invalid Username/Password.";
} else {
// username found, verify the password hash
if(!password_verify($post['password'],$row['password']))
{
// password doesn't match
$errors['login'] = "Invalid Username/Password.";
} else {
// password matches
$_SESSION['user_id'] = $row['id'];
}
}
}This post may be of interest:
I wouldn’t know about Access, by SQLite certainly is multi-user, although it locks the entire database, so is not suited for some applications.
When there are differences of understandings, as in here, it helps to provide an authoritive source. So first see SQLite Is Serverless. Then see Appropriate Uses For SQLite. It says SQLite works great as the database engine for most low to medium traffic websites. It does however say that file locking logic is buggy in many network filesystem implementations. It is not clear to me if that is relevant to website hosts and probably not.
I suppose the first question I would ask you is how many users are you going to have? Is this for 1 or 2 users or multiple users? If it’s for 1 or 2 and you don’t want to mess with a DB then you could use an if/then statement.
In order to avoid those complexities, it seems you’ll inherit other complexities. If you aren’t interested in learning to use databases, you might consider learning to consume APIs. Auth0 and firebase abstract the login away for you, but there is a learning curve.
This is what it boils down to.
Whatever method you use, be it a database, or some workaround to avoid using a database, it will involve learning something.
If you are not prepared to put the effort in to learn things that may be a bit of a challenge, my honest advice is to find another hobby.
My point was not so much to be discouraging, more to suggest that there are alternatives… But that none of them are easy.
It takes quite a lot to understand relational databases, and to get the idea of db libraries and their idiosyncrasies… Learning T-SQL is no joke, and it’s a never ending rabbit hole.
So am option to consider might be something like firebase - the auth interface is clean, document database structures might be easier to understand,
You still have to store the user’s data somewhere. Otherwise, if there is some kind of “save” state the OP wants without a database (whether that’s an actual database or flat files), that would be virtually impossible without losing the user’s progress. Sure, you can push it up to the cloud whenever the user is done, but how many requests per user does any kind of API really want to give you?