Member Avatar for mundetas

Hey can anyone please help me :S . I have created a user table with different levels for instance type 0 to 2. If the user is type 1 then a certain page will open . I have placed my values in sessions then used a condition to verify. Please help me because when the type 0 it goes to the right page. but if its 1 or 2 it displays a blank page does even echo the message I put in to show that the type is different.

<?php require_once ("inc/session.php");?>
<?php require_once("inc/connection.php"); ?>
<?php 
$username=$_POST["txtuser"]; 
$password=$_POST['txtpass']; 
$hashed_password=sha1($password);
?>


<?php 

$query="Select `id`,`username`,`type` From `tblusers` Where username=\"$username\" and passwordc=\"$hashed_password\"";

$result=mysql_query($query,$connection);

if (mysql_num_rows($result)==1)
{
$found_user=mysql_fetch_array($result);
$_SESSION['username']=$found_user['username'];
$_SESSION['type']=$found_user['type'];

//echo "it works";
if($_SESSION['username']==$username && $_SESSION['type']==1){
echo "<script language=\"javascript\"> window.location.replace(\"http:\/\/\localhost\/\Sample\/\test\/\test.php\");</script>";}
}
//else{
//echo "it dont".mysql_error();
//

if(!$_SESSION['type']){

echo "It recons ".$_SESSION['type'];
}


?>
</body>
</html>
  • 2 Contributors
  • 2 Replies
  • 101 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by mundetas

Dani AI

Generated

As reported, type 0 behaved differently from types 1 and 2. A blank page almost always means either a suppressed PHP error or a logic path that never outputs anything. Start by confirming two simple things: that a session is actually started, and that PHP errors are visible while you debug.

Common, actionable fixes and checks:

  • Turn on error reporting while debugging:
    error_reporting(E_ALL);
ini_set('display_errors', 1);
  • Inspect the session contents explicitly (use var_dump($_SESSION) or error_log(print_r($_SESSION, true))) to see the actual type value and whether the key exists.
  • To check for presence use isset($_SESSION['type']) rather than testing the value with !$_SESSION['type'] (0 is falsy). If you need to compare numeric levels, cast to int and use strict comparison.

A simple, safe redirect/check pattern:

session_start();
if (!isset($_SESSION['user_id'])) {
  header('Location: /login.php');
  exit;
}

if ((int)$_SESSION['type'] === 1) {
  header('Location: /member/level1.php');
  exit;
}

For better authentication and security: switch to prepared statements (PDO or mysqli) and modern password handling (password_hash / password_verify). Regenerate the session id after login (session_regenerate_id(true)) and store only the minimum (user id, role) in the session.

Protecting include files:

  • Put config/include files outside the webroot when possible.
  • If they must be in webroot, add an .htaccess in that folder with Deny from all (Apache) or configure the server to deny direct access.
  • Add a bootstrap constant check in includes (e.g. if (!defined('APP')) exit;) so direct requests stop.

Tie back to : strict type checks and viewing the raw session values will usually reveal the issue. If problems persist after these checks, check the server error log for fatal errors and verify any JavaScript redirects contain a valid URL (avoid malformed backslashes or broken quoting).

Recommended Answers

All 2 Replies

Member Avatar for noelthefish

I would check that the 'type' being returned is an int and not a char. If it is a char change == to ===

Member Avatar for mundetas

its an int I put a singles = . Any sugguestions on the best way to authentication in terms of user levels? How can you protect your files on an server so that the user doesn't see the include files etc.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.