I have a problem with setting cookies in an iframe (which loads a site from another domain).
On my site X.COM I load <iframe src='Y.COM'>
Y.COM tries to set cookies, but Safari blocks they, as this site was not visited before. So loading Y.COM fails because it can't work without cookies. Is there a way to solve this issue?
P.S. I cann't modify any data at Y.COM.
P.S.S. Also we can modify Safari's settings - "Accept cookies" = "Always", but it is not a solution for me - it seems to be impossible to lead every user to do it..
I experimented a similar problem. A web "parent" page open my "child" website in a jquery fancybox i-frame cross-domain. Not problem at all with Explorer, Chrome, Firefox, Opera and even with Safari (5.8.1) on MAC. But with iPhone, iPad and mini iPad, the session in the i-frame is lost.
That's mean that at every click on an element in the i-frame (web site is in aspx) a new session started.
We solve the problem in a very simple way:
when the parent website start, it call a page in the child site directly (not in an i-frame). In this page I just set a session variable and I redirect to the parent website. Now when the child website is open in an iframe, the session is kept.
Related
I'm not sure how to make this question reproducible because it requires having a Vimeo paid (or on a free trial) account.
Vimeo recently changed their UI for creators and made it harder to access one of the pages I use every day.
From https://vimeo.com/manage/videos there is a table with links to individual videos. The URL for each link is something like https://vimeo.com/55555555555555/settings.
If you click, it sends you to Page A: https://vimeo.com/manage/videos/55555555555555.
Then, there's a button that sends you to the page I actually need (Page B): https://vimeo.com/manage/55555555555555/general.
The problem is that when I enter the URL for Page B directly in my browser, it redirects me back to Page A.
Strangely, the back/forward buttons navigate between pages A and B, and the refresh button also stays in Page B. But if I copy Page B's URL, open a new tab and paste it, it sends me back to Page A.
To figure out what's going on, I looked in the network tab of the Chrome Developer tools and found that the first request from Page A to page B looks like this:
But then, if I paste that URL in a different tab, I get a 302:
I've diffed both requests:
Is there a way to prevent the 302 behavior?
I don't have a vimeo account and thus can not test it. Ultimately, the server could use any parts of the diff, but I'd expect it to use the referrer.
Does the page always direct you back if you completely disable setting the referrer in Chrome? If so, using a plugin to forge your referrer could solve the issue.
Unlike 301 redirects which are permanent, 302 are not. The web server displaying 302 errors should redirect the browser and take you to the new location immediately. It should be noted that HTTP 302 status code is due to the web server and not the web browser. There is no control at your end.
I created a canvas facebook app. The app itself was made in html and consisted of multiple different pages, the first page linking to the next, and so on... (links were assembled as simple html a tags with target="_self")
Everything seemed to be working fine in FF, Safari, Chrome, but not when we were testing in IE. It seems that redirecting within an iframe works different in IE, and it showed in the url of the browser:
When testing in FF,..., the url of the startpage would be apps.facebook.com/our-namespace, and after linking to the next page, this url in the browser would always remain that same apps.facebook.com/our-namespace.
When testing in IE, the url of the startpage would also be apps.facebook.com/our-namespace, but as soon as you hit one of the links, the url in the browser would change to apps.facebook.com/our-namespage/the-page-we-re-linking-to.php, not taking the target="_self" into account. When clicking on a comparable link again, the app would redirect to the start screen...
I spent hours trying to find an answer, I saw that changin IE's security settings would make it work:
in IE: go to Tools --> Internet Options --> Security --> Internet Zone --> Custom Level --> Miscellaneous --> Launch programs and files in an IFRAME. and make sure it is set to enabled
But this is not an acceptable solution as IE is configure different by default.
I found the solution was (in php) to add the following line to your code:
<?
header("p3p: CP=\"ALL DSP COR PSAa PSDa OUR NOR ONL UNI COM NAV\"");
?>
Problem solved! This should be in the facebook developer docs!!
I'm getting a strange issue only Chrome + Firefox. It doesn't repro on IOS or IE9.
Here's the repro:
Load Home page http://example.com
Login (via a rel="external" hyperlink). In my case I use Facebook's Oauth Server Side flow - so this URL is a facebook.com.
Facebook accepts the user's credentials and then redirects to http://example.com/user/callback. Here various facebook data is processed (it is provided in the query string).
The server side code at http://example.com/user/callback then redirects the user to http://example.com. The mechanism used for the redirect is a RedirectToAction from ASP.NET MVC3. This returns a 302.
Expected Result:
User would see a URL in their browser = http://example.com and the content all nicely shown. This works on IE and Safari.
Action Result (on Chrome Only)
User gets a URL in their browser = http://example.com/#base_domain=example.com
The actual page is blank (no visible content)
However a view source reveals that the content is present.
Action Result (on Firefox Only)
User gets a URL in their browser = http://example.com/#_=_
The actual page is blank (no visible content)
However a view source reveals that the content is present.
Additional Info
If I enter the URL http://example.com/#base_domain=example.com into IE I get the same 'hidden' content (i.e. blank page with HTML source still present).
I should also note I use the RedirectToAction/302 redirect technique in other parts of the application with no issues whatsoever.
The issue also repros with AJAX navigation turned off.
EDIT: This also works on Safari (OSX + Windows) with no issues. It's only apparently broken on Chrome + Firefox on both Windows and PC.
IOS/Safari: OK
Win/Safari: OK
Win/IE: OK
Windows Phone Emulator: OK
Win/Firefox: borked
Win/Chrome: borked
OSX/Safari: OK
OSX/Firefox: borked
OSX/Chrome: borked
Not sure about Android.
The best solution appears to be setting the Push State and Hash Listening to false - so chrome/ff completely ignore them. I already had AJAX navigation disabled (there some interesting behaviours with it I hadn't completely accounted for yet with my server side code).
$.mobile.pushStateEnabled = false;
$.mobile.hashListeningEnabled = false;
I'll probably wait for 1.1 and stabilise the rest of my code before trying to get AJAX navigation working.
I know this topic has been covered extensively, but I am totally stuck and in need of some direction and new opinions. I have a Facebook iFrame application that works perfectly in IE6,8, Safari, Chrome, FF, etc. Only IE7 gives me grief.
I have created a P3P policy file, and its associated XML file. The policy fully validates with the P3P policy validator.
As soon as the iFrame loads from within Facebook, the red eye icon appears and when I click it, it reports that cookies from the iFrame's domain are blocked. I have confirmed that the default 'medium' privacy setting is set on IE7. Interestingly I've found that by removing Google Analytics, the page will load initially without blocking the cookies, but as soon as the page reloads, or the user logs in, cookies are then blocked again even though the P3P header is sent immediately from every page. All assets are sent via S3, so there shouldn't be any issues there.
FYI, here's my P3P file; I've tried absolute paths, relative paths, switching order of CP and policyref, and separated the two into separate header calls with no luck.
header('P3P: CP="NON DSP TAIa PSAa PSDa OUR IND UNI", policyref="/w3c/p3p.xml"');
I have confirmed that the P3P Header is being sent and received by the browser. I have added a META p3p tag to the HTML page. I have removed all redirects. Still the issue persists. I've spent so much time looking into this, and I am now out of ideas. Any thoughts or ideas about how to approach this from a fresh perspective would be greatly appreciated. I'm using PHP 5.3.5 over NGINX. No framework being used...
I had the same problem. Facebook iframe app worked great in all browsers except IE7. When you first went to the app it loaded fine. But then when you clicked a link it would load the page okay but then after a second or so would refresh and redirect the browser. In the end you just got a blank page. I also had the red eye icon blocking the cookies.
The culprit turned out to be the javascript code which loads the facebook javascript lib:
FB.init({
appId : '<?=FACEBOOK_APP_ID?>',
status : true, // check login status
cookie : true, // enable cookies to allow the server to access the session
xfbml : true // parse XFBML
});
To fix the problem I changed status : true, to status : false. Now when clicking links the page loads and doesn't refresh.
So whats really going on here I am not sure but I have a guess...The redirect was being caused by the FB javavascript checking the login status and for some reason thinking the user was logged out and so redirecting to a login page. The server side login script I guess would then see that you had indeed logged in and redirect you back to the app. So on and so on.
So the problem of IE7 not setting the cookies set inside the iframe still exists, the evil eye remains. But as long as the links inside your iframe reference the parent window target="_top" pointing at the facebook canvas page it seems you don't need the cookie anyway. The PHP SDK looks for the session in a number of places starting with $_REQUEST. I am guessing that when facebook loads the iframe it includes the session param in the query string. So even though the cookies don't work in IE7 through the iframe your server scripts will still get them from the query param.
Hope that makes some sort of sense, I don't totally get it but it fixed my app.
i don't know but maybe this will help, it worked like a charm on my app.
header('P3P: CP="CAO PSA OUR"');
ob_start();
session_start();
I have a facebook Iframe application with multiple PHP pages in it.
I have some links that point relatively to the files inside my "iframe folder".
Having some issues with session variables inside the iframe. I set some session variables but they do not persist from one page to another.
This does work on other browsers.
I've been reading that Safari does not support Cross-Domain cookies and this might be the problem , but im not sure how to fix this.
Any help?
I believe this solution has become obsolete with the latest (6.0 and later) versions of Safari.
Safari by default does not allow cookies to be set from third parties. This affects Facebook iframe applications because the user is accessing a page served from apps.facebook.com but the iframe is being served from yourdomain.com, the "third party" in this case.
There are several several solutions mentioned around the web. The best I've found and one recommended by Facebook in its list of miscellaneous issues is to fake a POST request to yourdomain.com using JQuery. This solution detailed by Anant Garg works in general for different host/iframe domains and needs to be adapted for Facebook apps. The key parts are:
$("body").append('
<iframe id="sessionframe" name="sessionframe" onload="submitSessionForm()" src="http://www.yourdomain.com/blank.php" style="display:none;"></iframe>
<form id="sessionform" enctype="application/x-www-form-urlencoded"
action="http://www.yourdomain.com/startsession.php"
target="sessionframe" method="post"></form>');
var firstTimeSession = 0;
function submitSessionForm() {
if (firstTimeSession == 0) {
firstTimeSession = 1;
$("#sessionform").submit();
}
}
Another solution by Will Henderson is to instrument each link on your page with session information using a Javascript function. Then modify your server code to capture this session information by reading it from GET parameters.
I wrote the blog post Dominic refers to in his answer.
The problem is that the default behavior of Safari is to only accept cookies from sites that you visit. This excludes "third party" cookies. Safari treats the page inside an IFRAME as a third-party site, and until you interact with that content (by clicking a link, for example), it will refuse those cookies.
Your PHP code needs to set a cookie on the first page that uses the session in order for that session to persist from one page to another, but if the session variables are in the very first page in the IFRAME, you have a chicken-and-egg problem.
My solution is to retain all of the special Facebook parameters through to the second page loaded into the IFRAME. Because you've interacted with it, cookies set on the second page will persist, and this allows your PHP code to keep whatever state it needs to communicate back to Facebook.
This won't likely help your PHP session, though, so I suggest adding another parameter to links on the first page that allows the second page to look the session up, or otherwise recreate it.
I think the best solution is to manually keep track of the session ID i.e. by using session_id($_GET['session]); Just make sure you do this before calling session_start(); and everything works.
Safari accepts cookies only from the page the user navigates to. The easiest and most effective way to fix this is to redirect the request from landing page of your canvas app to a different page on your domain using top.location.href and redirect the user back to the canvas app from that page.
For example, if abc.php is your landing page and the canvas URL is facebook.com/abc. First redirect the request from abc.php to a different page like xyz.php then redirect again from xyz.php to facebook.com/abc. Don't forget to start the session in xyz.php.
This is the simple fix...
and thanks for all the input. I ended up solving the problem by appending the "signed_request" paramter on every page. I just put it in as a hidden field and set it in the code behind. That way I managed to get it to work in Safari. Hope it works for you too.
With the release of Safari 7, not only 3rd Party cookie is being blocked. Local Storage as well as WebDB, any kind of website data are being blocked. When you go to Safari Preferences (CMD+comma), Under privacy tab, on Safari 7, it now says : "Block cookies and other website", originally was "Block cookies". That confirms the changes.
Other browsers might follow through in the future. Most probably Firefox. Chrome, cough *cough* probably not.
You probably have to employ some workaround using redirection technique or popup similar to what disqus did.
If you using .NET then there is a much simpler solution to this problem.
Just set cookieless to false in your web.config. Ex:
sessionState mode="InProc" cookieless="true" timeout="60"
Its a lot easier than posting an iframe, or opening a popup window with the url of the iframe.
kind regards,
David
I used this header with PHP, that fix my problems
if ( strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE') ) header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');