I'm running a PHP script (on DOMAIN B) inside an iFrame on another domain (DOMAIN A).
When a user enters the site, a check is performed to see if they have the correct browser settings (cookies enabled AND third-party cookies enabled - however it is called in various browsers).
In order to do this, I set a session cookie $_SESSION['COOKIE_CHECK'] = 'passed'; from the iFrame (DOMAIN B), redirect to another script within the iFrame on DOMAIN B (header('Location: ...) and check if the cookie is still there. If not, an error message is displayed, otherwise the user is redirected again to the main script (also on DOMAIN B).
I'm making sure the session is active with session_start(); as the first line of code in all scripts. The header redirect is using the same (sub)domain for the target as the originating script.
This worked perfectly fine on all browsers (IE, FF, Safari, Chrome) for years until now. With the recent Safari update to version 13.0.4, this no longer works in Safari. It still works in other browsers.
I tried a few things including redirecting the parent document to the cookie check script on DOMAIN B and then back again. Nothing worked.
Any insight would greatly be appreciated!
Cheers and thanks in advance!
Tom
Related
The latest Firefox, version 63.0, on both Mac and Windows, has somehow broken the login I have built for the admininstrative backend of my ecommerce website. This was previously working fine. I use PHP.
On successful login with valid credentials a $_SESSION['admin_logged_in'] variable is set to TRUE and I am correctly logged in and redirected to a starting page. However when I then attempt to navigate to any other page within the admin site I am immediately logged out as if the session variable has suddenly been lost.
On every single page at the very beginning, including the starting page, I have an include with a short login check script which is as follows:
<?php
//start session
session_start() ;
//check user is logged in
if (($_SESSION['admin_logged_in'] !== TRUE) || (!isset($_SESSION['admin_logged_in']))) {
header("location: /index.php") ;
$_SESSION['admin_reason'] = "illegal" ;
exit;
}
?>
I may have thought this a bug with Firefox however recently I am also logged out, usually though after navigating through a couple of pages, by the latest version of Safari on iOS 12 and MacOS Mojave.
Currently working and no problems on Opera or Chrome (tested on Mac).
I have tried clearing the cache in Firefox and adjusting the privacy settings but no luck. I have spoken with my web hosts and they are not aware of any server side issues or changes.
But if there was a problem with the PHP code and session variables, since this is handled server side, presumably it would not work on any browser and also not worked previously?
Grateful for any suggestions.
I managed to solve this issue, please see my answer below.
I managed to solve this myself.
To clarify, issue on Firefox version 63.0 on both Mac and Windows, Safari version 12.0 on MacOS Mojave and Safari on iOS 12.0.1. Other browsers tested, Chrome and Opera, were fine.
I did some testing with a basic set of pages and found that in Firefox on all pages subsequent to any PHP session variable being set it was not available/did not exist. Safari usually lost it after navigating through a couple of pages.
I then discovered the following page of an old post on the Mozilla forums reference favicons:
https://bugzilla.mozilla.org/show_bug.cgi?id=263057
I checked developer tools and discovered that these browsers, every time in the case of Firefox, and every few pages in the case of Safari, were requesting favicon.ico and getting a 404 response since I did not have one there. For some reason this was breaking the PHP session variables. I am not clear as to why.
So the fix was simply to place a favicon.ico in the root directory of the website.
Thank you for your comments.
It's perhaps linked to new security policy that block some JavaScript or other resources used in your login system.
Check the Firefox web console https://developer.mozilla.org/en-US/docs/Tools/Web_Console/Opening_the_Web_Console
You may have messages like:
Content Security Policy: Ignoring “'unsafe-inline'” within script-src: ‘strict-dynamic’ specified
Content Security Policy: Ignoring “https:” within script-src: ‘strict-dynamic’ specified
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://XXX. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
We have about 100 users accessing our website daily. A majority of them have no issues logging in. However, once a month we get a call or email ticket with complaints that users just see the login page refresh, with no error messages or anything.
All error messages are sent through the PHP Session cookie, and of course everything after logging in is based off of that session. The only reason I could think that the page just refreshes HAS to be because they are blocking that session cookie on their local machine...
Now most often the user is on internet explorer, but occationally it even happens with Chrome or Firefox. I've even had a user (on OSX) who tried Safari, Chrome, FF - and it would NEVER let them log in, the page would just basically refresh. I had the user add the website as trusted, and still no luck.
It's the worst because I cannot reproduce it from any network or from any browser/computer, ever.
Does anyone know what could be causing something like this? The site IS forcing SSL (the HTACCESS file redirects to HTTPS). The site IS forcing the session cookie as HTTP-Only and the Secure flag is also set to TRUE (and these 2 are somewhat recent changes).
I'm unsure what other settings on the server or the PHP instance would be causing something like this, or if it's soley a client-side issue (which it appears to be). And if it's client side, I'd like to learn the issue and possible solutions to it.
To preempt everyone, no - I cannot share the website URL for debugging because the client would not appreciate that, unfortunately. Thanks for any help, I'll be happy to answer any question that I can!
Do you have more than one web server behind a load balancer? And are the PHP sessions stored locally on each web server? If so it is the load balancer's job to make sure a user keeps going back to the same server on repeated accesses. If something goes wrong, they could get sent to a server where they do not have a session. It could be some intermittent glitch sending users to the wrong server.
Just guessing, because as others noted, we don't really have enough info.
Does your session cookie have a valid name? I've run into this problem in the past where some browsers don't accept a session cookie if it has an invalid name, but other browsers do accept them;
http://php.net/manual/en/function.session-name.php
I have a website that requires a login. The logins are managed by an authentication token that is assigned to the target device (with a few others), but for some reason, its not working on Windows Phone. I have tested it on iPhone and all desktop browsers and it works on all of them.
I set it to show me the set cookies, and it is showing all the other cookies that have been set, except for the auth token cookie.
I tried changing the cookie name (to see if there was a collision with some redundant code running) but that didn't work (still working on desktop browsers).
I had placed a piece of code to detect the setcookie function call, which told me it was being called correctly. In the same code path of the login and setcookie I did a var_dump of the $_COOKIE then too and it showed that the token had been temporarily sent.
The code does contain the ability to detect a mobile browser, but it is unused (outside of a few small parts of the template engine).
An additional note about the code is that from the start, right up till the end, the output buffer is enabled, and only printed at the end of the code.
What else can I do to try to find the cause of the problem, or what could be causing the problem specifically for Windows Phone.
EDIT
I have just tested it on an iPad, and it is also not working. Very strange as it works on normal iPhones and the Safari browser.
EDIT
I have installed a server (AMPPS) on a computer on my LAN running the site (with the same db) and the login function works correctly.
In addition, during my tests, on the mobile (on the live version), the user is redirected to the users only page, but the cookie is not detected, and the user is returned to the sign in page. Other cookies are, but the auth token is not.
All of the cookies are set in the same way, with an expiry of time() + 3600, and the path set to '/'
I think I have fixed it. The code included some IP validation for the tokens, but for some reason, on those devices, the IP (returned from $_SERVER['REMOTE_ADDR']) is 127.255.255.255, which was incorrect. Not sure why it was doing that instead, but I have amended it so that the IP is not taken into consideration for invalid ips (such as 127.255.255.255) and it is working now.
I'm running a website in my own computer(with apache and php5.2) for developing, when I login user in the website(which will write a cookie) with IE, I can't logout. when I login with Firefox or chrome, the cookie was written in subdomain, which means I can't get the cookie.
but when I write the cookie, I'm pretty sure that I have set the path to '/' and domain to '.domain.com'.
Anyone have meet this problem?
so far I guess the problem maybe within the php configuration or apache conf.
Browsers don´t share cookies, you can´t access a IE cookie from Firefox.
I have simple php application, it works on all browsers except on IE8 beta 2, problem occurs when I try to update table field using Ajax call (jQuery post method). Using IE8 debugger I figure out that IE8 doesn't send session cookie so php scripts redirects to login page instead of executing requested action.
What can I do to make this work.
Edit:
I haven't mention that i was using Code Igniter so i have solved this problem by replacing Code Igniter default session implementation with native one. Code igniter default session implementation uses cookie to store all data.
Yesterday I had similar problem and found the solution. I hope this will help someone else also.
Problem: Suppose there's a website www.somewebsite.com and IFRAME inside it whcih loads php file from my server, www.myserver.com/welcome.php. Website was loading successfully as well as my welcome page and it showed something like "Hello Bob", so it successfully found user and logged him in.
Afterwards my JavaScript was making AJAX calls to another PHP file, and response was kind of in "not authorized" state, so SESSION data was completely missing. After page refresh, everything was working correctly. And this was happening only under IE8!
I thought that problem was with sending session cookies to the server, but when I installed Fiddler, I found that IE8 was sending cookies as well as PHPSESSID correctly, but server was kind of unable to detect correct SESSION object. Another strange thing was that 2nd time server sent following header:
P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
but first time no. After adding that header manually in PHP script, everything worked like a charm!
Then, when I googled that "p3p abracadabra", I found following web site:
http://adamyoung.net/IE-Blocking-iFrame-Cookies
Conclusion: Make sure that you're sending the header on every page that sets a cookie.
And this is not only related to IE8 + PHP combination, same problem happens in case of IE8 + ASP.NET, IE8 + JSP, etc.
I don't have IE8 myself, but your cookie might be blocked by Internet Explorer's strange security policies. A possible workaround can be to employ P3P (which is also the method for getting cookies working inside an IFRAME).
Generating the right P3P policy can be a bit of work, but you should be able to find the information you need at http://www.p3ptoolbox.org/
I had the same problem in IE8 RC1:
1)a user goes to the login page and a blank session cookie is set
2)The user logs in and a validated session cookie is set and javascript opens a new window and closes the current window.
3)The new window is opened and contains a blank session cookie.
4)The user is redirected to the login page
I changed step 1 so that the blank cookie was not set - I only send the session cookie if its been validated. This fixed the problem for me.
I am having trouble getting IE8 to use SSL Certificates (PK12) files as a means of authorization. If I want to protect a directory and force a matching web certificate to be present in the browser before granting access. It works fine with IE7 and all versions of Mozilla - just not IE8. It has rendered my wife's dictation system useless. One other thing I noticed is that when it sets the PHPSESSID cookie, it list the domain as .net and not mydomain.net.
As a workaround, you can embed the SessionID as a parameter on the uri.
See passing session id in the php manual.