What Does IE Do Differently

[CelticExile]

I am building a secure application when you are authenticated then I am storing a token in $_SESSION and in a MySQL database.  I spent all day grooming the PHP code and I am confident its fine mainly because this appears to be a client side problem.

 

In My Code

 

- Start Session

- Include a php file containing all the authentication functions

- Call the verification function (from the included file)

 

- If a user has not timed out AND if the user is allowed to use the system then the function returns "true" and we carry on.

 

-If a user is timed out they are whipped back to the log on page with a time out message

-If the user is not logged in they are whipped back to the log on page with an unauthorized message

-Both these are handled by verification function.

 

Now in IE it all works fine, every time.  In FF and Chrome it sometimes works and sometimes, it calls the verification function TWICE on each page.  I have put in an audit trail to check this and sometimes it calls it twice.  Now when it calls it twice and the user is authorized thats no problem it carries on as normal.  But if the user times out the first time it runs it stores the time out message and the second time (because I have cleared the log on credentials) it changes the message to the unauthorized one and so the user gets misleading information.

 

I would assume it was some concurrent dB access issue or $_SESSION variable time out issue but in IE, everytime it calls them once and in FF and Chrome half the time it calls it twice.  Also once its called the routine twice for the first time it seems to carry on doing so after that.

 

I can of course get round this by preventing the message overwrite but If anyone could shed any light I'd appreciate it.

[andrewgauger]

it calls the verification function TWICE on each page.

 

Disable all of your add-ons and try again.  Some of the debug tools that you can add on to firefox and chrome will execute parts of your code twice, once to navigate and second to debug. 

[CelticExile]

Thanks for the idea sadly, that was not the problem.

[de.monkeyz]

Are you by chance using the header() function somewhere? I think I had a similar issue a long time ago, and I think it was to do with that.

[CelticExile]

Yes I am using the header() thats how I am redirecting in the verification routine:

 

- first test is that the user is logged on

- If that fails the message is set to "Unauthorized" and credentials are wiped (user is logged off)

            - header() is used to redirect to the log on page displaying the message

- Second test checks if the log on has timed out

- If that fails the message is set to "Timed Out" and credentials are wiped (user is logged off)

            - header() is used to redirect to the log on page displaying the message

 

the problem is the verify goes to "Timed Out" the first time then on the second (unsolicited) run it appears as "Unauthorized"

 

I'll be very intrigued if you can shed some light on this

[de.monkeyz]

Could you post the PHP to this at all?

[CelticExile]

I am pretty much certain its not a PHP issue.

 

                $sessionParseTemp = $_SESSION[parsecode]; //Get The Token From The Session Variable
	$auth = getAuthCode();    //Get The Token From The Database
	//Checks User Is Authorized
	if ((string)$auth == (string)$sessionParseTemp)
	{
		//Checks If The Session Has Timed Out
		if (((date("U", time())) - decodeOutput($sessionParseTemp)) < 10) //Compares the Current Time To Stored Time
		{
                        // ********** Authenticates The User (WORKS FINE CONTAINS NO header() )
                        }
                        else
		{
                                //User Session has timed out
			$_SESSION[parsecode] = "-2";
			$_SESSION[errorcode] = "I'm sorry your session <b>Timed Out</b> please log in again";
			$_SESSION[errorchecker] .= 2;
			session_write_close();
			header('Location: clientlogin.php');
		}
	}
	else
	{
                        //User is not logged on
		$_SESSION[parsecode]="-1";
		$_SESSION[errorcode]="I'm sorry you're <b>NOT Authorized</b> to view this area.  Please Log In.";
		$_SESSION[errorchecker] .= 1;
		session_write_close();
		header('Location: clientlogin.php');
	}

 

$_SESSION[errorchecker]  is my audit train each successful verification adds 3 to a string.  Each time out adds a 2, each unauthorized a 1.

 

For Example:

 

Five verifications, four pass and the last one causes a timeout would/should display as "33332"

 

Sometimes I am getting stupid things like "33321"

[de.monkeyz]

Couple of things to note.

 

Array indexes when they're not numbers should be in quotes. And you should put an exit; or die; command after your calls to header();

 

The die/exit issue, MAY be causing the problem. I'm not 100% on that

[CelticExile]

Thanks for the tip in putting the array indexes in quotes did that.  I will now continue to in the future.

 

I put in an exit and it make no difference.  I didn't think it would as there is no code in the function after the header call.  Any other thoughts ?

[andrewgauger]

Thanks for the tip in putting the array indexes in quotes did that.  I will now continue to in the future.

 

I put in an exit and it make no difference.  I didn't think it would as there is no code in the function after the header call.  Any other thoughts ?

 

FYI it does matter, because it will continue to execute the entire page, not just finish the function.

[CelticExile]

Thanks for that. Andrew I will bear that in mind.

 

Ok I am still playing with this and I have some more information on what is happening.  Occasionally I was getting just a "1" out of the audit trail at the log on page and nothing else.  Because the login page clears the audit trail it seems obvious that the reason for the double verification calls is because the page is being called twice.  Does that information right a bell.  I am calling each of my pages using a hyperlink (or a form sending POST data) it does it for both.

[andrewgauger]

So it can be assumed that this test:

if ((string)$auth == (string)$sessionParseTemp)

is failing when it should succeed?  You need to do some debug of these variables then.  One of them must be set to something unexpected.  Print the variables and comment the header redirect and see if what I say rings true.

[CelticExile]

if ((string)$auth == (string)$sessionParseTemp)

 

is failing correctly (logically) on the second call because the db token does not match the session token (because the first time it was run the timeout logged out the user)  this causes the test to fail.  I know I can work around the test and I am doing that now but I would much sooner know why I FF and Chrome are submitting 2 page requests, sometimes per hyperlink.

[andrewgauger]

Right, that post doesn't correlate to your problem, sorry.  Do you have any client side javascript happening?  Try disabling scripting in firefox / Chrome to see if it is a client-side script that is submitting twice.  For all you know it could be analytics appended from your hosting organization.

[andrewgauger]

Also, try installing http://getfirebug.com/ to see if you can watch the headers to see if your server is redirecting twice.

[andrewgauger]

Add this?

 

header("Content-type: text/html; charset=ISO-8859-1");

 

https://bugzilla.mozilla.org/show_bug.cgi?id=236858

[andrewgauger]

According to the bug report, the absence of a "content-type text/html; charset=iso-8859-1" header or <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> meta tag in the page causes the browser to use it's default charset, which it may decide is wrong once it gets to process the actual data on the page. This is what causes the browser to re-request the page to be able to process it using the correct charset, hence submitting the form twice.

 

Let me know if the charset helps.  Or I might keep looking.

[CelticExile]

Disabling Javascript did stop the problem dead in its tracks but there are no scripts running onclick() of the hyperlinks and no onload() scripts.

 

I tried a few experiments and if I avoid running any scripts (including the hover over button scripts which seemed to be the root of the problem) then I don't get multi hits.

 

I just ran over all my buttons and then refreshed which gave me about 20 "3" returns.

 

When a script runs in FF and Chrome does it trigger a page refresh or something similar ?

[CelticExile]

I have fixed it! Your mentioning of the JavaScript got me thinking.  I tracked it down to my menu buttons.  When you hover over them they display an image and when you release them I wanted the image to go away.  It worked great I used the line:

elmnt.style.backgroundImage="url()";

 

This was tantamount to shoving a refresh into the header.  IE ignored the fault (or was happy with the Javascript) but the more correct FF and Chrome swooped in and sent me running round screaming.  I have now fixed it and its now running smooth and reliably.  I one hand I feel stupid for spending 4 hours on a problem with a picture but I also smarter for having tracked it down.  I won't make that mistake again....probably.  Thank you both for all your help I owe you both a drink.

[andrewgauger]

'grats