I have a facebook page tab iframe and would like to access the browser url in order to get the current facebook page url.
I know it's not possible to use a javascript that interacts with the parent frame because of browser security issues.
An approach that didn't work for all browsers was to read the HTTP_REFERER header from the request.
Is there a better way?
I hope this is impossible at all. Otherwise it will be a security issue, likely to be closed.
You should not write code depending on compromising other users.
It is not possible to get URL of a parent Frame due to cross-domain policy. And there is no way to get the information about page your application running on in client-side.
But on the server-side you can reconstruct the Page URL using details passed in signed_request. For Page Tab Applications it contains page:
A JSON object containing the page id string, the liked boolean (set to true if the user has liked the page, false if not) and the admin boolean (set to true if the user is an admin of the page, false if they're not).
Using that page id you can build the Page URL:
http://www.facebook.com/pages/-/PAGE_ID
If you want the link to your Page Tab with your application use:
http://www.facebook.com/pages/-/PAGE_ID?v=app_APPLICATION_ID
Beware, HTTP_REFERRER is provided by client and cannot be trusted, and it's may be cut by plugin/proxy/etc...
Notes:
Pages may have different URL in real life, but using this technique user will be landing the correct Page since Facebook will issue redirect to correct URL of a Page.
Sample URLs use HTTP scheme, feel free to use HTTPS if you need it.
In PHP for example you can detect the current scheme like this:
$scheme = ((isset($_SERVER['HTTPS']) && $_SERVER['HTTPS']!=="off") ||
(isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
$_SERVER['HTTP_X_FORWARDED_PROTO']=="https")
) ? 'https' : 'http';
HTTP_REFERRER might not work as expected in my experience. If the tab app is designed for a specific page (which I suppose it kind of should), have you tried recreating it?
https://www.facebook.com/MYPAGENAME/app_MYAPPID
Where MYPAGENAME is your page name and MYAPPID is the app id, of course.
If the tab is applied to multiple pages though, I'm quite sure you'll get the relevant data to apply the above from https://graph.facebook.com/PAGEID, where PAGEID is the ID of the page which you get from the signed request.
Related
Salon owners can create an account with their salon information on our platform and they get a page that they can use as a tab app.
I want to be able to serve all these pages from one app instead of having to install each one seprately and I also want to make the life of the salon owner easier by helping them to install the tab.
I know about the link I can create to help them install the app and I know that when a visitor visits the app that facebook will send the page ID. So far so good.
https://developers.facebook.com/docs/appsonfacebook/pagetabs/
But how do I make sure that when the salonowner follows the link to install the app that I get the page ID back (through callback or other) so that I can register which page ID belongs to which salon account.
I've read sone 2011 article about a callback but I can't find any recent info on this.
I think it should be possible as a lot of sites offer easy fb apps to businesses.
Any help would be welcome!
EDIT: Could this last piece of info in the Facebook link above be used to do this? I don't quite get it yet.
In addition, your app will also receive a string parameter called app_data as part of signed_request if an app_data parameter was set in the original query string in the URL your tab is loaded on. It could look like this: "https://www.facebook.com/YourPage?v=app_1234567890&app_data=any_string_here". You can use that to customize the content you render if you control the generation of the link.
Well... Preventing users from adding your application to their page is impossible. You can't prevent that.
What you will be able to do is to detect who has added your application and according to that, change the content (or not display it at all). So you'll have to start with a list of "allowed" page_ids to match to the accounts you want.
Your application will receive a signed_request each time a user arrives at your application (within a page). Inside that signed_request is information not only on the user but also on the page that the application is on (provided it is a page tab app).
Once you have obtained the signed_request, it will hold a page key which contains:
A JSON object containing the page id string, the liked boolean (set to
true if the user has liked the page, false if not) and the admin
boolean (set to true if the user is an admin of the page, false if
they're not). This field is only present if your app is being loaded
within a Page Tab.
So you'll be able to access the page_id from within this variable and make a decision on the type of content you want to be displayed.
Ok, after running some tests I found out that when you add a URL as 'next' parameter to the install URL Facebook will send the admin(user) back to this URL while adding an array to the request containing all the page Id's the app was installed to.
Like this: YOUR_CALLBACK_URL?tabs_added[ID]=1
Proved to be quite easy in the end
I have an application running in an iFrame that is embedded in a SharePoint site. The problem with this is navigation within the application does not result in a change in the SharePoint site URL. Therefore, if you were to refresh the overall page, you would be sent back to the default page of the application, not stay on the same page of the application. The reason this is an issue is sharing for social media. I have added a Facebook Share button to the application, but when it pulls the URL of the application which does not match or reference the URL of the overall site, so it just shares the application (which is not visually appealing and does not allow you to access the rest of the site).
Any body have any suggestions or know a place I can go for help? Thanks!
If I understand properly, the Facebook stuff is INSIDE the iframe?
If so, you can:
* Remove the iframe and integrate the application better with SharePoint, or
* Change the application so that it detects that it's running "alone" (with javascript etc), and if so redirect to the "big" application.
IF the Facebook stuff is in SharePoint, OUTSIDE of the iframe, you can write some javascript to update the URL in some way that matches the URL of the application. This requires that the SharePoint parent application and the iframe application run in the same domain - if they are not, this is not an option.
Note that changing the "parent" URL with JS will reload the page, UNLESS you only change the URL after the "#" part (so you can do something like:
"http://sharepoint/iframe.aspx?aa=11&bb=22#iframeUrl=http://uglyapplication/"
You'll also probably want to write JS to update your iframe accordingly if the user press "back"/"forward" etc in the browser, because changing the URL like above will still add a "step" to the browser history.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Play Framework appending #= to redirect after Facebook auth via OAuth2?
Has anyone else seen this happen?
I am building a Facebook canvas app using the Facebook PHP SDK, and some Javascript.
Now when I take the user through the OAuth authentication flow, I have noticed that the URL in the browser automatically gets appended with this "#_=_" , so my URL starts looking like this:
http://apps.facebook.com/xxxxxxxxxxxx/#_=_
and when I redirect to the app profile page the URL is this:
http://www.facebook.com/apps/application.php?id=xxxxxxxxxxxx#_=_
I am redirecting using
echo "<script type='text/javascript'>top.location.href='$appcanvasurl';</script>"
to the canvas URL, and
echo "<script type='text/javascript'>top.location.href='$appprofurl';</script>"
for app profile page.
So why is this #_=_ getting appended?
Update:
According to this bug on the tracker, this is by design, and giving a value for the redirect_uri does not change this.
And according to the official facebook reply on that page (have to be logged in to Facebook to view the post):
This has been marked as 'by design' because it prevents a potential security vulnerability.
Some browsers will append the hash fragment from a URL to the end of a new URL to which they have been redirected (if that new URL does not itself have a hash fragment).
For example if example1.com returns a redirect to example2.com, then a browser going to example1.com#abc will go to example2.com#abc, and the hash fragment content from example1.com would be accessible to a script on example2.com.
Since it is possible to have one auth flow redirect to another, it would be possible to have sensitive auth data from one app accessible to another.
This is mitigated by appending a new hash fragment to the redirect URL to prevent this browser behavior.
If the aesthetics, or client-side behavior, of the resulting URL are of concern, it would be possible to use window.location.hash (or even a server-side redirect of your own) to remove the offending characters.
See This:
https://developers.facebook.com/blog/post/552/
Change in Session Redirect Behavior
This week, we started adding a fragment #_=_ to the redirect_uri
when this field is left blank. Please ensure that your app can handle
this behavior.
We're hosting a PHP facebook canvas application (http://apps.facebook.com/myapp). One of the pages (http://apps.facebook.com/myapp/foobar) requires authentication from facebook so we can access some information about the user. This is achieved by using the PHP-SDK's $facebook->getLoginUrl() method to generate the url for authentication and works as expected.
We have since added the app to as a Tab (iFrame) to our Page (http://www.facebook.com/MyPage?sk=app_nnnnn). Now when we try to authenticate the user they are redirected to the app's url (http://apps.facebook.com/myapp/foobar) rather than having the /foobar page load in the Tab's iFrame as expected.
Is it possible to set the auth so that it doesn't bounce to the app's url but stays within the Tab using the PHP-SDK? If so, what is the workflow I should follow to achieve this?
I would simply add code to http://apps.facebook.com/myapp/foobar to check for authentication, and if it is, echo:
<script type="text/javascript">
top.location.href = 'http://www.facebook.com/MyPage?sk=whatever';
</script>
That should break out of the iframe and redirect you to where you want to go.
The way I have achieved this is to do the following:
On the /myapp/foobar page I check to see whether the user has been authenticated. If they haven't I set a session value and use the PHP-SDK's $facebook->getLoginUrl() to generate the auth url and send a response back containing just the javascript to redirect window.top.
Once they've authenticated they're redirected back to the main page. When this page loads it checks for the session value and, if set, removes it and issues a redirect header to /myapp/foobar.
It's a little convoluted but seems to be quite a stable solution.
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"');