Jump to content

[WARNING] super invisible bug! Can GURUs solve this one? Not sure...


Recommended Posts

here is an odd bug i am running into and cant seem to figure out wtf is going on. maybe one of you has encounter something similar?

 

i am encountering a really weird bug this one page i log in from the index page and i  go to many different pages and everything is fine but then i got to this page c lets say  and it logs me out but when i log in the second time and do the same procedure and go to page C it does not log me out...

 

This is what happens for example

 

a) I log in

b) go to page A

c) go to page B

d) go to page C > site logs me out and sends me back to index page to log in again.

 

So at this point I log in for the second time and do the same thing

 

a) I log in

b) go to page A

c) go to page B

d) go to page C > Page works perfectly and it does not log me out.

it only happens at the same page.

 

they all use the same two include files

 

which is connect

	$host = "";
$user = "";
$password = "";
$database = "";
if (!($db = mysql_pconnect($host, $user , $password))){
  		die("Can't connect to database server.");    
}
else
{
  		if (!(mysql_select_db("$database",$db)))
	{
      		die("Can't connect to database.");
    	}
} 

 

and session

 

	session_start();
$sessionuser = $_SESSION['username'];
$sessionpassword = $_SESSION['password'];
$userid = "";
$sessionquery = "SELECT id FROM user WHERE username = '" . trim($sessionuser) . "' AND password = '" . trim($sessionpassword) ."'";
$query_sessionresult = mysql_fetch_array(mysql_query($sessionquery));
if (mysql_affected_rows() < 1)
{
	header("Location: ../index.php");
}
$userid = $query_sessionresult['id'];

 

It sounds like the hostname/subdomain is changing - www. verses no-www. on the domain name and the session cookie is not setup to match both URL's (with and without a hostname/subdomain.)

 

The first time through you are probably using URL's of one type. When you get to page C, the URL changes to the other type. When you go back to the log in page it stays as the type of URL that matches page C and it remains as that type so that when you get tp page C again the session cookie matches the URL you are using to get to page C and your session is resumed whereas it was not the first time you reached page C.

 

If this is what is happening (what are your actual URL's?), you need to set the domain portion of the session cookie settings to match your domain independently of having or not having a www. hostname on it.

PFMaBiSmAd you nailed it right on the head, I was about to come over here and say that since i just figured it out too. However I did not know the solution.

 

 

But i dont use cookies or know how to use them, can you help me with it?

 

Also is there a way to do it without cookies?

 

By default, the session id is propagated using a cookie. To set the domain portion of the session cookie parameters, you need to use - http://us2.php.net/manual/en/function.session-set-cookie-params.php See the third parameter and you need to do this before every session_start() statement.

 

It is often better to globally set the session.cookie_domain in a .htaccess file (when php is running as an Apache module) or in a local php.ini (when php is running as a CGI application.)

in the session include file, shouldn't this:

$sessionquery = "SELECT id FROM user WHERE username = '" . trim($sessionuser) . "' AND password = '" . trim($sessionpassword) ."'";
   $query_sessionresult = mysql_fetch_array(mysql_query($sessionquery));
   if (mysql_affected_rows() < 1)
   {
      header("Location: ../index.php");
   }
   $userid = $query_sessionresult['id'];

be

$sessionquery = "SELECT id FROM user WHERE username = '" . trim($sessionuser) . "' AND password = '" . trim($sessionpassword) ."'";
   $query_sessionresult = mysql_query($sessionquery);
   if (mysql_num_rows($query_sessionresult) !== 1)
   {
      header("Location: ../index.php");
   }
   $query_sessionrow = mysql_fetch_array($query_sessionresult);
   $userid = $query_sessionrow['id'];

in the session include file, shouldn't this:

$sessionquery = "SELECT id FROM user WHERE username = '" . trim($sessionuser) . "' AND password = '" . trim($sessionpassword) ."'";
   $query_sessionresult = mysql_fetch_array(mysql_query($sessionquery));
   if (mysql_affected_rows() < 1)
   {
      header("Location: ../index.php");
   }
   $userid = $query_sessionresult['id'];

be

$sessionquery = "SELECT id FROM user WHERE username = '" . trim($sessionuser) . "' AND password = '" . trim($sessionpassword) ."'";
   $query_sessionresult = mysql_query($sessionquery);
   if (mysql_num_rows($query_sessionresult) !== 1)
   {
      header("Location: ../index.php");
   }
   $query_sessionrow = mysql_fetch_array($query_sessionresult);
   $userid = $query_sessionrow['id'];

 

Whats the difference?

A SELECT query does not set mysql_affected_rows() (first piece of code), it sets mysql_num_rows() (second piece of code) and you need to test how many rows are in the result set before you use mysql_fetch_array() and the header() redirect needs an exit; statement after it to prevent the rest of the code on the page from being executed.

A SELECT query does not set mysql_affected_rows() (first piece of code), it sets mysql_num_rows() (second piece of code) and you need to test how many rows are in the result set before you use mysql_fetch_array() and the header() redirect needs an exit; statement after it to prevent the rest of the code on the page from being executed.

 

thats odd, it seems to work, i been using it all through out my code and it always returns the right number. Am I missing something?

In the original posted code, the header() redirect is probably failing and then the remainder of the code is being executed anyway, so it would 'appear' that the code is working.

 

If the code has a previous INSERT, UPDATE, REPLACE or DELETE in it, mysql_affected_rows() could also return a value and make it 'appear' that the code is working.

 

The posted code is not correct.

PFM I think you might be wrong on this one.

 

I just executed this code to test it

 

include("/include/cms/connect.inc.php");

$result = mysql_query("SELECT * from user");

echo mysql_affected_rows();

 

and it returned the correct number of rows.

 

this is the include file

$host = "";

  $user = "";

  $password = "";

  $database = "";

  if (!($db = mysql_pconnect($host, $user , $password))){

        die("Can't connect to database server."); 

  }

  else

  {

        if (!(mysql_select_db("$database",$db)))

      {

            die("Can't connect to database.");

   

 

as you can see there is no insert update replace or delete.

It might be returning the expected value, but don't count on it. This is the current definition -

Get the number of affected rows by the last INSERT, UPDATE, REPLACE or DELETE query associated with link_identifier .

 

Php.net has a history of introducing changes (both documented and undocumented) that are later undone. Someone may in fact have altered the base code so that mysql_affected_rows() does the same thing as mysql_num_rows(), but it is not documented, so don't rely on it (the people in the past that have relied on 'undocumented' features in php have gotten burnt by using them.)

 

Both rhodesa and I are trying to get you to use the correct function in your code that we know will work now and later. What you have now cannot be guaranteed to work outside of your current version of php/mysql.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.