cags Posted October 23, 2009 Share Posted October 23, 2009 This is an odd one, I have a site which has an admin section. The admin pages unsurprisingly require you to be logged in to access them. Each admin page has the following at the top to check that the user is logged in... session_start(); require_once 'settings.php'; if(!isset($_SESSION['logged_in']) || empty($_SESSION['logged_in'])) { header("Location: " . ROOT_URL); exit(); } On the login page the following is what occurs on a successfull login... $_SESSION['logged_in'] = TRUE; $_SESSION['user'] = $row['name']; $_SESSION['id'] = $row['user_id']; header('Location: ' . ROOT_URL . 'admin/acp.php'); exit(); If I access my site on Firefox, Chrome or Safari, the login works fine and takes me to the admin landing page of admin/acp.php, the problem occurs if you access it on Internet Explorer (ver. 8.0.6....). Upon successfull login Internet Explorer redirects to ROOT_URL and continues to redirect you there if you try and access any admin page. To the best of my knowledge there is nothing in this code that could cause this to happen regardless of the browser used, so I feel the problem is being caused by the domain forwarding and possibly what domain the session cookie is considered active on. Let's say our url is http://www.example.co.uk (and this is the value stored in the constant ROOT_URL). The site is hosted on a free webhost and is setup with the domain name of http://www.example.comlu.com. http://www.example.co.uk is set to forward as a frame to http://www.example.comlu.com. So I'm guessing this is causing the problem, but what I really can't understand is why it only does it in IE Any ideas or suggestions on how to fix it? I know the best solution would be to get http://www.example.co.uk's nameserver to correctly point to the webhosts nameserver and activate the url on the account, but that's not currently going to happen. Quote Link to comment Share on other sites More sharing options...
severndigital Posted October 23, 2009 Share Posted October 23, 2009 How is the ROOT_URL constant being set? you could maybe code around with using the $_SERVER['HTTP_HOST'] instead. Quote Link to comment Share on other sites More sharing options...
cags Posted October 23, 2009 Author Share Posted October 23, 2009 ROOT_URL is set in the only manner I know of setting a constant using define. Yes I could use $_SERVER['HTTP_HOST'] but it would completely defeat the point of owning http://www.example.co.uk, as it would change the URI in the browser. If I wanted that to happen I could just scrap http://www.example.co.uk and stick to using http://www.example.comlu.com as the constant. Quote Link to comment Share on other sites More sharing options...
purpleshadez Posted October 23, 2009 Share Posted October 23, 2009 Is it possible that its a cache issue with IE? Had a similar(ish) issue with a machine at work that despite logging in to the intranet cookie was present and correct but it kept presenting the page as though no one was logged in. cleared the cache and it was okay again. Quote Link to comment Share on other sites More sharing options...
severndigital Posted October 23, 2009 Share Posted October 23, 2009 What happens if you log in using IE and then when it craps out, manually type in the address of the place you want to go? if you use the same tab, it should keep your session active. if this works, it's something in the code bugging out IE (what a surprise right), if it does the same thing, then it's gotta be something with the forwarding. Quote Link to comment Share on other sites More sharing options...
mrMarcus Posted October 23, 2009 Share Posted October 23, 2009 it obviously wouldn't be server-side, so as mentioned, i'd focus in on cache and cookies. try using some cache control headers in your admin directories: header("Cache-Control: no-store, no-cache, must-revalidate"); header("Cache-Control: post-check=0, pre-check=0", false); header("Pragma: no-cache"); Quote Link to comment Share on other sites More sharing options...
cags Posted October 23, 2009 Author Share Posted October 23, 2009 What happens if you log in using IE and then when it craps out, manually type in the address of the place you want to go? if you use the same tab, it should keep your session active. if this works, it's something in the code bugging out IE (what a surprise right), if it does the same thing, then it's gotta be something with the forwarding. If i manually type in the same address that would work in Firefox etc it just redirects me, which means the session isn't working correctly. Is it possible that its a cache issue with IE? Had a similar(ish) issue with a machine at work that despite logging in to the intranet cookie was present and correct but it kept presenting the page as though no one was logged in. cleared the cache and it was okay again. I don't see how it can be a caching issue because it's been attempted on 4 differen't computers from 3 differen't locations. it obviously wouldn't be server-side, so as mentioned, i'd focus in on cache and cookies. try using some cache control headers in your admin directories: header("Cache-Control: no-store, no-cache, must-revalidate"); header("Cache-Control: post-check=0, pre-check=0", false); header("Pragma: no-cache"); I'll try it, but I don't hold out much hope. Quote Link to comment Share on other sites More sharing options...
cags Posted October 23, 2009 Author Share Posted October 23, 2009 Hmm... it's definately the domains. I tried going to http://www.example.co.uk/admin/ and logging in, I then went to http://www.example.comlu.com/admin/acp.php and successfully got to the page. However http://www.example.co.uk/admin/acp.php redirects back. It appears that for some reason IE see's the session as invalid on that domain wheras the other browsers don't. So I used a web developer toolkit for Firefox to see the active cookies. It shows... http://www.example.co.uk/admin/acp.php - 0 Cookies http://www.example.comlu.com/admin/acp.php - 1 Cookie (host example.comlu.com/admin/acp.php). I don't know how to check IE's cookies to compare values, but it doesn't half seem strange that it acts differently. Quote Link to comment Share on other sites More sharing options...
mrMarcus Posted October 23, 2009 Share Posted October 23, 2009 so, the two sites in question are completely different sites? are they being hosted on the same server? my thoughts are that there could be a time zone discrepancy with IE and expiring of cookies because of that. just a thought. and excuse my confusion .. when you're on http://www.example.co.uk, you are then viewing http://www.example.comlu.com via an HTML frameset? i didn't quite catch exactly what you meant, and knowing might allow me to help more efficiently. Quote Link to comment Share on other sites More sharing options...
cags Posted October 23, 2009 Author Share Posted October 23, 2009 The site it hosted by a free webhost, which provided the http://www.example.comlu.com domain free of charge. http://www.example.co.uk is a domain name owned by the same person registered through bt. I have logged into the bt account and set http://www.example.co.uk/ to forward to http://www.example.comlu.com, selecting frame forward as opposed to URL forward because the objective is to keep the viewable address as http://www.example.co.uk. They are not exactly the same site nor infact are they differen't sites as such. There is no content hosted on one of the servers, it is just a URL setup to forward visitors. Quote Link to comment Share on other sites More sharing options...
mrMarcus Posted October 23, 2009 Share Posted October 23, 2009 oooold post, but give it a glance .. might still be relevant: PHP Session / Cookie in Frames Using Internet Explorer Quote Link to comment Share on other sites More sharing options...
cags Posted October 23, 2009 Author Share Posted October 23, 2009 Hmm thanks mrMarcus, that looks very promising. It certainly seems to describe the exact issue I'm having so I'll give the proposed solution a go. Quote Link to comment Share on other sites More sharing options...
mrMarcus Posted October 23, 2009 Share Posted October 23, 2009 no problemo. it has to be something along those lines .. what else could it be? Quote Link to comment Share on other sites More sharing options...
cags Posted October 23, 2009 Author Share Posted October 23, 2009 Whoop, whoop, that fixed it. I added the following header to both my login and check_login.php scripts. header('P3P:CP=”IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT”); It said on the article you linked, to add them before the cookie is created so it's probably not required on check_login I'll experiment and find out, but at least it's working. I don't however like using code if I don't know what it's doing, so I'm going to have to do some research. I've found on w3.org that P3P denotes, Platform for Privacy Preferences, but I haven't currently found anywhere explaining what any of the substrings mean. Any information I have found about the whole thing seems to be very old, I'm surprised it still applies. Quote Link to comment Share on other sites More sharing options...
mrMarcus Posted October 23, 2009 Share Posted October 23, 2009 good stuff, man. Any information I have found about the whole thing seems to be very old, I'm surprised it still applies.microsoft must really think this is a necessary measure to be taken .. the article is from 2006 i believe, so they've had quite some time to make any necessary changes in the several new versions of the IE browser since. perhaps it's a good thing? an added security measure? or is it just IE improperly handling information again? like you said, this is also something i know nothing about either (never heard of P3P (Platform for Privacy Preferences) before today) .. gonna do some reading myself. Quote Link to comment Share on other sites More sharing options...
cags Posted October 23, 2009 Author Share Posted October 23, 2009 I hadn't heard of it either, I can't really be bothered at the moment to get too bogged down in technical information so I've been look around for a summary. From the information I've found it appears that there is no actual method for enforcing the accuracy or the privacy ticket anyway. Lastly, before you can call yourself an expert, you must be aware that all this P3P stuff still doesn't specify any sort of evaluation of compliance. A site may well be lying through its teeth about what it does with user data, but, if the policies are in order, the browser is happy. The policy must list a course of action for the user to take in the dispute resolution process, and in most cases, that can be the Direct Marketing Association. Source Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.