Active / Deactive User



Hi everyone, I am fairly new to PHP and can't get passed a certain spot in my login. Currently I have an admin page that can update, delete any user that registers. I also have a column in my database table that is designated for active / nonactive users. Once registered, my insert script automatically adds a 1 under each user in the active column. What I am looking for is if (admin) changes their active to 0, they can no logger login. I have a very simple login.php file. IIs there any way I can add a function to my existing login.php file to check if a user has a 0 or a 1 under active in the database table and not allow users with a 0 to login??

Here is my login script:


if (isset($_POST['submit'])) {
	if (empty($_POST['user']) || empty($_POST['pwd'])) {
		header("Location: login_empty.php"); 

		} else {
	if ($user==("****") & $pwd==("****")) {
		header("Location: admin.php");
		} else {
			$query = mysqli_query($con,"SELECT * FROM people WHERE user='$user' AND pwd='$pwd'");
			$rows = mysqli_num_rows($query);
			if ($rows == 1) {
				header("Location: user.php");
			} else {
				header("Location: login_failed.php"); 

Any help would be greatly appreciated.

Thanks, Steve


Aside from the glaring security weaknesses of storing un-hashed passwords in combination with passing user input directly into sql statements, it's quite simple:-

SELECT * FROM people WHERE user='$user' AND pwd=$pwd AND active = '1'

Note the additional condition on the end.

Though this system seriously needs to change to something even close to secure.
Learn about "SQL injection" and "Prepared Statements". Also learn about the password_hash and password_verify functions.
And ask if unsure.


Sam, thank you very much. For what it is used for, just friends use it for the most part. No need to make the login completely secure. I am going to put hashing in the registration page.

Again, thank you very much!!! Didn't realize how simple it was.



That may be OK on a closed internal network, but the on-line world is unfortunately full of unpleasant people (and robots) that scour the net looking for vulnerabilities to exploit.
So it is something to always be mindful of for anything that's on-line for any use. Half the battle is just being aware of the threats that exist, the other is knowing how to guard against them.

Another note, I don't see any sessions being set on login before the redirect. What happens if for example you bypass login and go directly to admin.php by typing the URL?


You want to be using a logical AND here

if ($user==("****") & $pwd==("****"))


if ($user=="****" && $pwd=="****")

and the inner sets of brackets are unnecessary.


Yeah, I know there are terrible people out there just trying to mess with peoples web sites... The first one I built (with a friend, mostly his code, my idea) got hit by robots every once in a while. I am going to do what I can to prevent that again. I am slowly learning things and what to do.

My site allows you to login on the index page, which I have (required_once) calling out pages to start the session and the login page and so forth.. That does bring up a point I haven't thought of, if you know the name of the admin page, you could cause havoc. Not sure how to prevent that type of situation. I still have some major hurtles to battle before the site is fully functional, along with some minor fixes, as you pointed out. Just want it completely functional first, than can tweak it. If you know where I can find something about posting from a dynamic pulldown, I'd love to read about it. That's my next big hurtle. Got the pulldown to work from the table, just can't seem to post a submitted pick from it. I love coding tho....


Thank you!!! Already changed.


Equally terrible are the developers out there who build websites who have no idea what they doing in the first place leaving HUGE open security vulnerabilities to exploit. It is like leaving you car running, key in ignition and door open with the title in the glove box and not expecting someone to come along and steal the vehicle.


Huh, if I didn't know better, that was a shot on me. I understand what you are saying, but the code I shared is to get working code that I have an issue with, then I plan on adding more security to it. I take criticism extremely well as I am new to this, but not finger pointing. When I am finished and if the site is shared to people outside of the friends that use it, then tear it apart as needed. I would completely appreciate that. Thank you for the small help. I learned my lesson with asking questions to get help here..

If I'm reading your response wrong, I apologize. But since there was no answer to my question(s), just criticism, that's how it came across.


Except for the fact that anybody who knows where to find this site (and has a minor clue what to do) is able to read out and wipe your database - having your data exposed to unauthorized persons is only one part of the problem:

the neglect of hashing the passwords does not only encounter the data you took responsibility to host it for your friends to get in the wrong hands: this specific issue may enable attackers to login on other services with your friend's credentials and the password they gave in your hand.

Just a friendly advice by experience: there's a good chance you won't, or when it's too late. Security is inherent behavior of a software that can not easily be patched without major changes - as SQL Injection is one of the major flaws in webdevelopment, Prepared Statements are one of these security concepts (essential as a backup) that should be applied just from the beginning, and they are so easy there's no excuse not to make use of them.

That may also give you a slight inside of why you get these responses so heavily.


Thank you for the advice, I appreciate it. After the response(s) I have already had, I am adding hashing to the registration now.


Something to also note, do not use MD5 or sha. These are low level hashing algorithms and they have been obsolete for 20 years. Also, do not create your own hashing algorithm. Use password_hash() and password_verify() when dealing with hashing passwords. These functions are created by people who understand cryptography. Something neither you nor I would understand. So creating unsafe hashing algorithms with MD5 and sha would leave your site to have more security risks.


Great heads up, thank you!!


Even if absolutely nobody but you use it and it never goes online, it is a good idea to harden your code. True, you may never intentionally try to do something wrong, but speaking from personal experience, there have been rare times when I unintentionally did something (like a bad copy paste into an input etc.) where having safeguards in place saved me from needing to fix a mess.


I didn't mean to be disrespectful. In the same instance I think its the devs responsibility to secure what they build. Either way it is difficult to judge competence on a forum. Students or entry level people making these types of mistakes / oversights is acceptable someone who has been in this industry for several years and making a good living not so much. I have found it funny that people always thought the mysql_* adaptor was the problem concerning injection vulnerabilities yet time and time again people are making the same mistakes with mysqli_ and PDO. In some cases the problem has become even worse because people no longer even use escape functions and just embed raw data in queries. Exactly as you have done.


I'm hoping this is still a good way of doing it but i have used to create a login system. It does most of the clever work for you. Please correct me if this is now outdated.

The other really simple thing to do is really make it clear that the user should use a different password than they use for other things (inc the email). The biggest issue is if someone hacks your site and gets a list of emails and passwords that then allow them to get into a users email. they can then check if that user does internet banking etc and start resetting passwords and the like.

If would be your fault for not securing their details on your site, and the users fault for using the same password for everything.



No. This is outdated. I had to move someone's library using that to password_verify because it had so much errors when I switched to PHP 7. I couldn't contact the owner too because they made it impossible to find their contact info.


oh darn. Is it insecure in itself or just doesn't work on php7? is there an alternative you can point me to of a similar product?



I don't recall the exact error message. I believe it was the hashing algorithm altogether. This was a year ago when I updated the owner's library to using password_hash.

You should really be using password_hash and password_verify. They aren't really that difficult to use. For password_hash, you just have to remember that it has 3 arguments. First argument is the unhashed password itself. The second argument is a constant and there's 3 different algorithms you can use for it, but the manual recommends that you use PASSWORD_DEFAULT in case the other 2 algorithms aren't supported anymore. Using PASSWORD_DEFAULT will automatically default to the latest algorithm that is supported. And the third argument is optional and is the cost. The cost has to be an array with cost as an index and an int as the value.

password_verify is even more simple. Only requires 2 arguments. First argument is the unhashed password and second argument is the hashed password. And that's it.


thanks for that. something else to brush up on. Everytime you think you have something sussed the game changes :slight_smile: