LeJack

You need to wrap this inside the isset if statement. If you just plain code it after the session is set, you'll get an error.

You need to check if the session is set first. If it isn't, then show the custom error page. It looks like you're just trying to put the question mark before the session. That's not going to work. SAMPLE: if(isset($_SESSION['sample_session'])) { echo "Session cookie is set"; } else { echo "Session cookie needs to be set first"; } Or you can do it the other way around. if(!isset($_SESSION['sample_session'])) { echo "Session cookie needs to be set first"; } else { echo "Session cookie is set"; }

I see that you're not too familiar with PHP. I suggest you learn it from the official website because that will help you much more. If you learn it from a tutorial, you won't get any where. In addition, you're placing your edits in the wrong places. echo '<img class="alignleft" src="' . get_stylesheet_directory_uri() . '/images/default-image.jpg" alt="Shares & Derivatives Left" />'; Take out all those double single quotes. You're placing them where they aren't suppose to and you're placing them where you don't have any PHP codes. You need to learn the basics of HTML too if you're not sure where to put the double quotes.

That's procedural to OOP. He's doing OOP to procedural which doesn't work. You can't use new mysqli if you're using procedural. You can only use mysqli_connect if you're using procedural and if you're using OOP, you can only use new mysqli. Both achieve the same thing. It's just different coding styles that's different. Edit: He's getting the Boolean error because he's combining OOP with procedural. Since OOP doesn't have that kind of coding style. mysqli_fetch_array doesn't work. It has to be $mysqli->fetch_array(MYSQLI_BOTH) if you want to use both associative and numerical arrays, but you can use $mysqli->fetch_array(MYSQLI_ASSOC) if you want to use associative arrays. If you want numerical arrays, you can use $mysqli->fetch_array(MYSQLI_NUM)

You're using OOP with procedural. You can't do that. It's either stick with procedural or stick with OOP. You're best bet is to stay with procedural since you're more familiar with that.

@ginerjm If you're not going to be helpful to people, you might want to stray from trying to insult their codes like someone on this forum does. You might just get a taste of your own medicine. @shmideo I don't believe there's any kind of function that's named "chn". In addition, if you're just trying to connect to a database, you might want to not mishmash old deprecated libraries with new libraries. Using both mysql_ and mysqli_ together won't work. There are actually 2 ways of connecting to a database. Most typical way is the procedural way since I've been seeing that a lot with people trying to switch over to the new mysqli. The first one is obivously mysqli_connect and the second one is new mysqli. The only thing I don't like about mysqli_connect is you have to add another line just to connect to your database while you can just do it with one with the new mysqli. Here's a sample for the new mysqli. <?php define("DB_HOST", "localhost"); define("DB_USER", "username"); define("DB_PASSWORD", "password"); define("DB_DATA", "database"); $mysqli = new mysqli(DB_HOST, DB_USER, DB_PASSWORD, DB_DATA); if($mysqli->connect_errno()) { printf("Connect failed: %s\n", $mysqli->connect_error()); exit(); } $query = $mysqli->query(""); Here's a sample for mysqli_connect. <?php define("DB_HOST", "localhost"); define("DB_USER", "username"); define("DB_PASSWORD", "password"); define("DB_DATA", "database"); $mysqli = mysqli_connect(DB_HOST, DB_USER, DB_PASSWORD, DB_DATA); if(mysqli_connect_errno()) { printf("Connect failed: %s\n", mysqli_connect_error()); exit(); } $query = "..."; mysqli_query($mysqli, $query);

The thing about ginerjm's first post is that cookies can be manipulated since it's on the user's side. If it was on the server's side, it would be a different story. Storing cookies is a bad idea. Example: 1. User spams a form and gets locked out with cookies. 2. User right clicks -> View Page Info -> Security Tab -> View Cookies Button -> Deletes all cookies associated with the current domain. 3. Goes back and spams the form more. 4. Repeats all 3 steps. This will then be considered a brute force attack because the user is attempting to get into a credential page by abusing a broken security rule. The only thing that cookies should exist is if you have a login system that logs a user on. Even then, you should be using sessions and not cookie. Cookies are not a good sign of security. The average Joe knows everything about cookies. It's the mainstream version of sessions. Not every Joe knows what sessions are and how they operate while the average Joe knows everything and all about cookies. It's obvious where the exploits will come from. My suggestion, don't use cookies or sessions. The best way on going about this would be log the user's agent, IP Address, timestamp, the requested page they were on, and amount of attempts in a table. Then while you lock the user, you should redirect them to a page where it lists ways of verifying who they are even if they run on the same IP Address. I don't think this is a bad idea at all. Let's say you have a group of guests who are visiting you for a day. You find that your $500,000 bracelet was stolen from one of the guests. Are you going to do what everyone does and try to find the fastest and best way possible to get your bracelet back by calling the police? No, what a smart person would do is lock all of the guests up in a room and then interrogate them one-by-one. That's basically what we are doing here. You don't want to find the fastest and best way possible to lock a user by using sessions, cookies, what ever. You want to know who it is and what they are doing. Same with interrogating them one-by-one. You should interact with users who have been locked. This is so that they can verify/ prove that they aren't the culprit. We are using the user's agent because then we can detect if the user is using which browser to access your website. If the person attempting an attack uses let's say Google Chrome, but the person who was verifying that it's not them are using let's say Netscape, then you know it's not them. We can also report this attack to the user's browser agent whether it'd be Mozilla Firefox, Google Chrome, Safari, Opera, .etc. We can request those browser agent to track who is doing this and block their access or we can do many other things. We use their IP Address because this would give you a few seconds to detect how frequent the user is visiting your website. It doesn't matter if the user is using a proxy, it's still going to be blocked either way if the user attempts to fail again. We use timestamps to detect which time of the day they are doing this attempt. Then we use the page they're on so that we know exactly where the security vulnerabilities are so that we can fix these pages for future situations. Last but not least, we track how many failed attempts they have tried in order to gain access to your blocked page. This is so you know how to replicate the attempt again or if the user has stopped attempting completely. If you aren't the one who did it, you wouldn't be attempting the same methods over and over again. You would probably contact the website's owner and let them know that this was a mistake. Only guilty people attempt new methods of trying to attack. If you lock their IP Address and they contact you and you unlock them and then it starts happening again, you already know who is doing the attacking.

Yeah I would have to go with Frank_b and ginerjm on this. It is nearly impossible to have a login system without any type of database to it. Although it does say no cookies or database, you can always use sessions if they didn't say you can't use it. Like Frank_b and ginerjm said, you could use a text file to store these user datas. Normally, I'd suggest .csv files. .txt files aren't normally used for these things. .csv files are more easier when it comes to editing them via a file editor.

It's simple. Just place If ($user) { /* Logout Script */ } else { /* Login Script */ } Where your login form was. Place your login form inside the else statement and then put what ever you want in the if statement. If you want us to give you the answers, you won't learn anything.

It kind of sounds like he configured his .htaccess wrong or maybe even his php.ini. You normally don't get 500 error if you aren't messing around with your .htaccess. It's either he's using PHP tags in his .htaccess or something.

That's weird because when I tried it on my localhost, it works just fine.

Use sessions instead of cookies because cruel people can delete cookies and the average Joe knows everything about cookies and where they are stored. The average Joe however doesn't have access to sessions so you should be ok until you find one that knows how to execute sessions using their own applications.

When you use <?php echo $_SERVER['PHP_SELF']; ?> You will end up with http://example/index.php No matter how much you try to change the URL in the address bar, you'll always end up with the file and the file's extension. If you want just the file without the extension, then you'll have to use <?php echo $_SERVER['REQUEST_URI']; ?> . When you use <?php echo $_SERVER['REQUEST_URI']; ?> You end up with http://example/index So you won't really have to change the action in your form every time. It will automatically do it for you. What it does is, it takes the file path of the URL, so if your URL is http://example.com/I_will_only_show_you_once It will always show the exact URL ending. It won't take http://example.com, you'll have to define that yourself. That can simply be accomplish by adding a few more stuff to it. Here's your final code. http://<?php echo $_SERVER['REMOTE_NAME']; ?><?php echo $_SERVER['REQUEST_URI']; ?> When you use <?php echo $_SERVER['REMOTE_NAME']; ?> You only get the website name and not the actual http URL. If your site is http://example.com or http://facebook.com, it will always only show example.com or facebook.com. The "http://" part matters a lot. That's why you should type in "http://" yourself if you want to also include the full URL. It's the same thing as just using the REQUEST_URI method. There is also another way of submitting forms. If you aren't targeting another page in the action form, you should leave it blank because it doesn't make any sense to specify the page name in the action form if you are just targeting itself. Such as <form action="test.php" method="POST"> And then that form belongs in the "test.php" file. Then why not just do this? <form action="" method="POST"> You'll still get the same result if you leave the action blank. It'll help you in the long run since you aren't going to have the .php file extension if the URL doesn't end with .php This is basic HTML with basic PHP. Your issue doesn't have a lot to do with Apache configuration.

That's not even the whole point. The whole point of you letting the person read what for 30 seconds and then forcing them not to. Here's what will happen. User 1 visits page http://www.example/page-a.php Page http://www.example/page-a.php sets a cookie for 30 seconds. Page http://www.example/page-a.php redirects to http://www.example/page-b.php User notices that the 2 pages uses cookies. Immediately goes and delete cookies. Abuses this right. Can either do a cookie injection You're basically letting the person do anything bad. Even though you might set a cookie on the front page so they get redirected after 30 seconds, you still need another set of cookies in order to remember if the cookies is set or not. In the end, you're just leading yourself to injections every where. What I suggest is use sessions because sessions are back end and you can always delete sessions at a certain time. It's not just there to be deleted after the browser is closed. You can always specify when and where the session is deleted. Sessions act just like cookies. They remember what the person does. Try this code for a second and tell me if you can delete it without knowing session_destroy() <?php session_start(); $_SESSION['example'] = "30 seconds are up"; echo $_SESSION['example']; ?>

Cookies are a bad idea. What makes you think the user won't just delete the cookie by right clicking > Page Info > Security > View Cookies > Delete specific cookie. Just use sessions instead of cookies because sessions works better and it's server side so the user won't see the cookies.

o. o Add what 2 lines? You didn't specify which 2 lines and you are asking for help. Please provide your code that you have that you are stuck on. No one on this forum will debug your code for you. If you want someone to do your work for you, you should head to the freelancer part of this website. Otherwise, please give us details on what you are stuck on. Is your code giving server errors? Is your code running, but doesn't display the specific material/data that you wanted? Is your code NOT working at all? Are you having problems with setting up your database? And so on. Again, no one on this site will code for you. The thing I find funny is that there are so many people out there that thinks programming is super easy, but what they don't know 1 thing about it at all. You may think it's easy to code right now, but even programmers run into problems themselves so how is programming easy? First thing people always forgets is security and that's why their applications get hacked the most. Sigh, people give the wrong impressions on the IT Departments.

Also, please note that appending the i after mysql will not work. You have to legit know how the MySQLi library works. As of now, 000webhost is supporting PHP 5.4 which means they're probably going to remove the older MySQL library.