I have a site made with php which uses server side sessions throughout the site.
In fact, it's a site with a user login which depends on session variables and if there were a problem with all session variables, no pages would load at all.
On the site, there's an iframe that holds a feed of little messages from other users.
Those little messages have clickable photos next to them that open the user's profile.
Now, each page requires some formatting to open the user's profile on that specific page...there's really only a few problem pages, but those pages have to have the onclick functions formatted a little differently or they break the page.
So I set a session variable on each page ($_SESSION["current_page"]) that lets the feed know how to format the clickable photos. Now Firefox, Opera, Chrome, Safari all work as they are supposed to.
But IE6 and IE7 are having problems on the pages that require special formatting.
So after pulling my hair out a bit, I eventually got around to printing my session variables form the server.
And lo and behold, on the special pages, ($_SESSION["current_page"]) is always set to "main" instead of "special1" or "special2".
I printed the same session variable in Firefox and all the other browsers I mentioned and they print out "special1" or "special2" as they're supposed to.
Can anyone think of something - possibly related to the fact that the feed is in an iframe??? - that would cause IE to treat server side session variables differently or somehow launch page "main" silently in the background?
I have checked the feed very carefully for any reference to page "main" - it doesn't seem like there's any ways it's loading that page.
this doesn't make sense to me.
Check the name of the server machine. IE has problems with machine names that contain '-' or '_' - they cannot maintain a session! I've had this problem twice in the past, and it always takes me weeks to figure out, and I'm shocked IE hasn't fixed it.
Just rename the machine to have no strange characters! You can get it working if you just use the IP address of the server in the url to test.
IE has cookie issues with it's handling of iFrames which maybe causing the session issue you mention, take a look at these links
http://adamyoung.net/IE-Blocking-iFrame-Cookies
http://gathadams.com/2007/06/25/how-to-set-third-party-cookies-with-iframe-facebook-applications/
http://nileshtrivedi.in/blog/2008/09/01/iframe-cookies-and-internet-explorer/
Try testing the page while using some sort of monitoring proxy (I use Fiddler) and see what pages the browser requests. That might give you some clues to what's going on.
Also, try capturing the requests/responses from different browsers and see what IE is doing differently (order of requests, content of requests?).
To pinpoint the problem, can you rewrite the code without using SESSION (it's mentioned in one of the other answers)? Maybe IE is accessing the pages in different order than other browsers? Maybe it is requesting the main page more than once, which means that the session var is set to "main"? Without session variables, the pages won't affect each other's state.
In most cases, this php line at file begining will be enough:
header('P3P: CP=”NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM”');
If it isn't, for IE7 you may also try:
header('P3P: CP=”NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM”');
header('Set-Cookie: SIDNAME=ronty; path=/; secure');
header('Cache-Control: no-cache');
header('Pragma: no-cache');
And if that doesn't work for IE6, you may use GET params for session ID:
header('location: land_for_sale.php?phpSESSID='.session_id());
I thought some people might find the solution to this problem interesting. Fiddler certainly helped here. Thanks to Fiddler, I could see that I was, in fact, hitting the page main.php (thus setting the session variable moments after setting it on the target page), but the server was defaulting there after getting a 302 on the root of the site. This was all happening silently in the background, and before my onload="" javascript ran.
So I was sure something on those pages was causing an error, but not a catastrophic one.
here it is: <img src= "" >
IE was freaking out about the blank src attribute and hitting the server root and the defaulting to page main. I don't fully understand the mechanics happening here. I also don't understand if this is how IE is supposed to behave (it is a malformed img tag after all) or not. Is this a bug?
I found if you added header('P3P: CP="CAO PSA OUR"'); to the top of your doc. It seems to have fixed the problem.
I had this problem, and it was due to the date on my dev box being out. Firefox didn't mind, IE and chrome were seeing the session as being expired as soon as it was set.
I have the same problem and it's SOLVED now.
The blank or empty attribute's values of any IMG tags cause the problem.
For me, I used JavaScript to change IMG object's source to an empty value.
Doing that could also make the problem.
If I understand it correctly, you are trying to use a session variable to pass data from a page to pages within iframes on that page? This doesn't seem a good way to go about it - why not just pass a GET variable into the iframe url i.e. ?current_page=special1 . I would think this would be more reliable as it does not rely on session state.
Remember also that the session variables will be the same for several pages of the same site that are open on a user's PC (e.g. on multiple tabs), which could cause odd behaviour.
Session data is stored on the server side, not the client. I would check the other pages, where this value would be set.
I had the same problem with ie7 and this is what I do:
If you have this problem using a IIS or Apache in Windows Server, look at the URL where you are redirecting it must be writed in the same way as the URL where you was before the redirection.
For example:
site.com/pages/index.php redirection to site.com/Pages/index2.php is going to loose the session in IE7 because the capital letter in Pages.
Maybe it's session.cookie_lifetime. I have faced the same problem. I updated session.cookie_lifetime: 4500 to session.cookie_lifetime:0. This means the session cookie never expires until the browser shuts down.
Related
Note: I have updated and rewritten my question to try and solve this issue point by point. Cheers.
I have a problem and I'm not immediately sure how to go about resolving it.
I have been building a secured login system on a HTTPS server (with a grade of "A" by SSL-labs, if that's worth anything ), and it works fine, however today it is refusing to log me in, with some debugging I have found something very odd (in my view).
I have some serious issues with session handling on the website, the different pages use the same session data (of course) and the same session /cookie settings, and they pass the information between each other correctly, BUT the behaviour of my browser appears to be as if there are two browsers visiting the same websites, using the same session data.
Symptoms - Because I have been having inconsistencies with page generated session content (unique hash token) not fitting the same data saved in the login form (as a $_POST value), I was finding that as there is only one line in the whole site that sets the value of the session, this line must be running twice. So I set a counter value in the session, on the form page as session['counter']. each time the page loads, the counter +1's. My problem is specifically with this:
Login page:
Opens page,
session hash-string is generated and saved to the post form.
session counter = counter + 1;
Form is filled in.
Login auth' page:
fails to verify the posted hash-string is the same as the session hash
string, despite there being no other cause for the session values to
change (well there must be, but I can't see it!)
But, then going back to the Login Page I see that the counter = last value + 2! Also, the counter value recorded on the session file saved on the server is always +1 to the value displayed on the login page.
Some images:
Login Form Page: Please note that this is above the HTML output and is the last place on the code where any SESSION data is edited.
Output :
Please note the number relating to the counter in image 1.
My session file, this file relates to this specific browser session and only 1 session file as I am the only browser on the site.
The string CheckDrop is the hash value to compare but the counter is at 12 rather than 11, which is displayed in image 2 above.
My site is HTTPS authed although this work is on a subdomain.
This issue has been happening for the last 3 hours but inconsistently, it magically worked for about 40 minutes earlier today (just before posting this post). but I had done nothing I could see as changing the environment.
I have previously compared phpinfo data and session setup data it all looks correct at point of browser output. It does not seem to be caused by my settings.
It happens on different browsers on my PC.
Further Work
After spending hours debugging and working through this, it appears to be a browser issue. I have renamed the pages (one page was called index while it was not defined in .htaccess as the directory listing page which may have possibly caused a browser to open it twice).
I have cleared all associated data: sessions / database records / browser history, and have come across something:
Firefox now logs in as expected, the counter is count+1 and the login works, however on Chrome the exact same log in on the same pages does not work and the browser appears to load twice, the counter = counter + 2. Chrome also leaves two records in the database at each load rather than the expected one.
Chrome version 45.0.24
Firefox version 42.0
Page double counts and runs script twice on Safari and Chrome. On Firefox, Opera and MSIE it works as intended.
Any ideas why this is occurring?
How can I go about trying to solve this problem?
The original issue was caused by the naming of the webpages, there was a webpage named "index.php" but this page was NOT the index, instead "loggedIn.php" was the index page for the site, as defined in .htaccess
Having an index.php page that was not an index seemed to confuse a lot of browsers. This [part of] the issue was resolved by renaming all the pages and setting an index.php page that used PHP headers to redirect people to the suitable page (based on if logged in or not) .
The issue remained with Chrome and Safari.
After a long time reading lots of issues about Chrome, the solution was frankly pathetic,
https://code.google.com/p/chromium/issues/detail?id=64810
This link lists various issues relating to this problem of Chrome double loading, if certain markup elements are not present. As my page above are very simple, there wasn't a lot that applied, but Google Chrome will silently request the favicon.ico file and then if it doesn't find it, will reload the page but only output the first page (from Chrome memory cache).
This is an epically stupid bug in Chrome that has cost me most of a day. Safari still persists in loading the PHP script twice,
I might be a little late to the party, but I've found another reason why this was happening for me. I created the following page:
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<?php
error_log('Loaded');
?>
</body>
</html>
Even this minimal page was loading twice, but only in Chrome, so I started investigating, and found Mendeley Web Importer Chrome extension to be causing this behaviour. Simply disabling it solved the issue for me.
I suppose your problem is with Internet Explorer... I had the same problem and I discovered, with incredible surprise and shock, that internet explorer 10 will send a different "user agent" value, from request to request.
When I saw it for the first time I was really impressed by the absurdity of the fact, but that's completely sure. I tested it very deeply and you cannot trust the Internet Explorer "user agent" string to be the same from request to request.
I had to remove that string from the hashing login string
I have a php system that works fine stand-alone but not when embedded in an iframe.
It's embedded in a page on another domain.. and consists of:
main.php graps a parameter off iframe-URL, look up in MySQL, sets a session variable and draws a grid.
Then, using ajax, tries to get data to display in the grid.
- but the ajax.php doesn't have the same session_id() ?!?
AND in subsequent ajax-calls for data (to update the grid) the session_id() keeps changing!
To recap: ALL my PHP is inside the SAME iframe - no XS trouble..?
There IS a session_start() in all the right places (it works stand-alone).
The session_save_path() is the same in main.php and ajax.php (and they're in the same dir)
I've seen and tried different versions of header('P3P: CP="CAO PSA OUR"') - fruitlessly : (
Found it: My browser didn't allow Third Party Cookies - including the session-cookie!
But isn't this wrong - no cookies are being shared across domains (it stays inside the iframe) ?
- still.. it IS another domain than the one the user asked for in the URL... hmm... shit.
As mentioned, the problem was the browser blocking (not allowing) Third Party Cookies.
(That is, ignoring cookies not issued from the server behind the main (visible) URL)
There exists a way to circumvent this security-feature: google "P3P"
- but that's not reliable across browsers (Chrome).
My solution is to keep the session_id in javascript, and append it as an extra parameter in all ajax-calls,
enabling me to pick the relevant session in ajax.php: session_id( $_POST['sessID'] ); session_start( );
This solution does make it somewhat easier for a malicious user to dick around with the session_id.
- since it's now available (for modification) using javascript alone (easier than modifying a cookie)...
I would like to hear peoples thoughts about this "increased vulnerability" ?
Apologies if this question duplicates some other question, but I can't find one exactly like it in S.O.
I am writing a remotely hosted app, the kind that runs when you put a javascript on your own website page, where the src="some remote javascript.js". so, the script operates by calling every operation as a jsonp ajax. A lot of jsonp housekeeping, but otherwise works surprisingly well.
In the main remote js script, I set a user cookie when the user logs in. It works fine, the cookie is set for a year, and when you return to the page it continues recognizes you.
However, when I try to output the cookie (even after it has been set) using php, my php code does not see it for some reason.
If I alert(document.cookie); the cookie is displayed.
If I do a var_dump($_COOKIE); php returns array(0) { }.
This isn't a "you have to reload the page after setting the cookie with javascript" problem.
As far as I know, when I use the Firefox Web Developer extension to View Cookie Information, it is all happening on the same domain.
Looking over many other examples, it is clear that PHP should be able to read a cookie, even if set by javascript.
Even as I write this, I think a glimmer of what the problem is is starting to form in my head, that (possibly) a JSONP'd php script isn't going to see the cookie set by javascript.
So in most current browsers there is the feature of Tabs, is there a way to get the Tab index?
so Tab 1 has www.google.com opened in it and Tab 2 has www.google.com opened in it, is there a way to identify what the Tab index is?
Pseudo Code:
if($tab == 2) {
alert "Tab 2 is active\n";
}
if($tab == 1) {
alert "Please use Tab 2 as this is Tab 1\n";
}
Funny as everything I search for about tabs is related to the tab index of the webpage itself, sigh...
Strictly speaking. TABS are on the end user's machine. PHP works on the server. PHP can't see what the end user's machine is doing, it can only serve the end user PHP'ed pages.
Google does this with JavaScript and Cookies. For every instance of the page opened, increment a cookie counter. If the counter > 1, use AJAX to display an error message. Also, prohibit the page from functioning if cookies or JavaScript is disabled.
Look into jQuery.
As far as determining the absolute tab index, I know of no way to do it with Javascript. You can identify windows by their names, but not anything else.
In your example of two tabs containing the same web page, you should be able to uniquely identify them by making them aware of each other. You'd need to use cookies for this. Essentially, when a page is loaded, it would check for a cookie that tells it about other instances of the page that are currently loaded, and make decisions accordingly.
In this scenario, your onload handler would check the cookies, and register the loading page. You'd also need an onunload handler to unset the cookie pertaining to the page being unloaded.
See Javascript communication between browser tabs/windows for more information on how to use cookies to communicate between windows with Javascript.
in php: definitely not - it's executed on your server without access to the cleints browser.
maybe there's a solution using javascript (but i've never heard of that, and i'm pretty sure this isn't possible too - at least not as a cross-browser solution).
i think the best chance you'll have (if there even is one) is using other client-side languages like flash, silverlight or a java-plugin as this ones can do a lot more than javascript - but i'm sorry i don't know any of these good enough to give more information or hints.
Don't waste anymore time on this mate. It isn't possible, mainly because any webpage inside browser will not be able to get this kind of information due to security restrictions.
Try looking for an laternative approach as some of the other guys have suggested in their comments.
I am sure there is not a global variable for support that information. But maybe clever browsers such as Firefox or Google Chrome might support something on it. I have made a quick search on net and I came with these.
First, check Mozilla Tab Helper can be work with Mozilla. But be remember, this will never be a cross browser solution. Also, I am thinking there is not a cross browser solution.
Second one is, if you want to use this for your own use then it might bu useful, I don't test it. This is a addon. Here is the Open Tab Count Mozilla Addon
Open Tab Preview
I've to admin a small website for my alumni group which is hosted by my ISV. The url is something like www.myIsv.com/myWebSite/ which is quite ugly and very forgetable. The main admin of the webserver has registered a domain name www.mysmallwebsite.com and put a index.html with this content:
<html>
<head>
<title>www.mysmallwebsite.com</title>
</head>
<frameset>
<frame src="http://www.myIsv.com/myWebSite/" name="redir">
<noframes>
<p>Original location:
http://www.myIsv.com/myWebSite/
</p>
</noframes>
</frameset>
</html>
It works fine, but some features like PHP Session variables doesn't work anymore! Anyone has a suggestion for correcting that?
Edit:
This doesn't work both on IE and on Firefox (no plugins)
Thanks
Sessions are tied to the server AND the domain. Using frameset across domain will cause all kind of breakage because that's just not how it was designed to do.
Try using apache mod rewrite to create a "passthrough redirection", the "proxy" flag ([P]) in the rule is the magic flag that you need
Documentation at http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
What do you mean?
Are you saying that when you go from www.mysmallwebsite.com to www.myIsv.com/myWebSite/ then the PHP session is lost?
PHP recognizes the session with an ID (alpha-numeric hash generated on the server). The ID is passed from request to request using a cookie called PHPSESSID or something like that (you can view the cookies a websites sets with the help of your browser ... on Firefox you have Firebug + FireCookie and the wonderful Web Developer Toolbar ... with which you can view the list of cookies without a sweat).
So ... PHP is passing the session ID through the PHPSESSID cookie. But you can pass the session ID as a plain GET request parameters.
So when you place the html link to the ugly domain name, assuming that it is the same PHP server (with the same sessions initialized), you can put it like this ...
www.myIsv.com/myWebSite/?PHPSESSID=<?=session_id()?>
I haven't worked with PHP for a while, but I think this will work.
Do session variables work if you hit http://www.myIsv.com/myWebSite/ directly? It would seem to me that the server config would dictate whether or not sessions will work. However, if you're starting a session on www.mysmallwebsite.com somehow (doesn't look like you're using PHP, but maybe you are), you're not going to be able to transfer session data without writing some backend logic that moves the session from server to server.
Stick a session_start() at the beginning of your script and see if you can access the variables again.
It's not working because on the client sessions are per-domain. All the cookies are being saved for mysmallwebsite.com, so myIsv.com cannot access them.
#pix0r
www.myIsv.com/myWebSite/ -> session variable work
www.mysmallwebsite.com -> session variable doesn't work
#Alexandru
Unfortunately this is not on the same webserver
What browser/ ad-on do you have? it may be your browser or some other software (may be even the web server) is blocking the sessions from http://www.myIsv.com/myWebSite/ working from with-in the frame, as its located on a different site, thinking its an XSS attack.
If the session works at http://www.myIsv.com/myWebSite/ with out the frame you could always us a redirect from http://www.mysmallwebsite.com to the ugly url, instead of using the frame.
EDIT:
I have just tried your frame code on a site of mine that uses sessions, firefox worked fine, with me logging in and staying loged in, but IE7 logged me straight out again.
So when you place the html link to the ugly domain name, assuming that it is the same PHP server (with the same sessions initialized), you can put it like this ...
www.myIsv.com/myWebSite/?PHPSESSID=<?=session_id()?>
From a security point of view, I really really really hope that doesn't work
You could also set a cookie on the user-side and then check for the presence of that cookie directly after redirecting, which if you're bothered about friendly URLs would mean that you don't have to pass around a PHPSESSID in the query string.
When people arrive # www.mysmallwebsite.com I would just redirect to http://www.myIsv.com/myWebSite/
<?php header('Location: http://www.myIsv.com/myWebSite/'); ?>
This is all I would have in www.mysmqllwebsite.com/index.php
This way you dont have to worry about browsedr compatibility, or weather the sessions work, just do the redirct, and you'll be good.