I have a standalone PHP web app which consists of several pages in a checkout style process, the user posts a form on each page to the next with the collected data.
I am trying to port this to a Facebook Canvas app.
What is the best practice for posting forms from page to page in a Canvas app? Should I just post as normal with a form target of _self? If I do that though I understand I might not get the signed request on each page.
Correct, when you form post to _self, then you will not get a signed_request. You should hold the user information in some server side storage such as a session object.
Related
I am working on an application that needs to allow users to access the Facebook posts of their friends. However, the Facebook API does not allow access to the posts of other people.
I am aware that scraping the users web page for the data is illegal, and was curious if it would be unethical to simply display the Facebook page with the relevant information, rather than to scrape the data and integrate it directly in my app?
I don't see why this would be illegal, but I also don't see much of a difference between just displaying the web page, and reading the web page for the relevant data.
I would like to make users to be able to post stories to their timeline but with no links to any resources. Using Facebook example:
I would like this post not to have any links. If someone using facebook on a browser clicks the image or the Cookie! title, they will be redirected somewhere. In my case, they are directed to an URL on my api which stores object data as meta tags from where FB scrappes the information (in this case, a blank page where the headers describe the Cookie! object). Is this even possible? I am developing an app for ios with no website, this is why I need to do this.
I'm planning on launching a website and an accompanying facebook page. Although each of these 'sites' will have their own goal, I'd like to have a 2-way sync set-up for part of the user generated content on my site, such that:
Content published on my site (by editors, or users) that satisfies some criteria are pushed to the wall of the accompanying facebook page
The other way around: content published on the facebook page wall by users, is pushed to my website. (I want to be in complete control of how to format, display, annotate that content, so I'm not looking for some ready-made widgets)
For 2. I'm pretty sure I can poll for a newsfeed or channel of the specific facebook page at regular intervals, but I'm wondering if a tighter integration is possible, i.e: pushing the changed content(delta's, river whatever you want to call it) to a dedicated rest-endpoint from which my website can consume the contents or something.
For 1. I need an automated way to post to the wall of the facebook page I own. Preferrably with the user-credentials (if okayed by the user) if that user was logged-in on my site through Facebook, or otherwise with some fallback credential, e.g: my own facebook credentials.
Just looking for some pointers where to start looking in the vast Developer Facebook resources, or, better yet, some libraries (prefferably Node.js, but others are okay to look at architecture) that take care of some of the plumbing
1) You can post on page with different ways
as a user : You need user access token and he should be a fan of the page or If your fan page allows wall posts from any user in its settings.
as a page : You need page access token
You can get page access token and extend it for long time and store it in DB. You can use it 60 days.
FYI:
Extended access token
Tutorial
2) Using graph API you can pull at regular intervals. There is a real time notification system also but it very limited for pages (its not useful for your case).
FYI: Real Time Updates
I'm building an app using Backbone.js and a private API that serves assets and JSON.
Most content in the app is accessed through the root '/' and the Backbone router serves up views based on the hash (ie /#about or /#view).
The problem is that when a page is shared to Facebook, it scrapes the main page and seems to disregard anything past the hash mark.
Are there any good rules of thumb for url paths or content that is not highly dynamic to make the app more presentable to Facebook, Google, etc?
Google has some good info on making AJAX apps crawlable.
https://developers.google.com/webmasters/ajax-crawling/
You could create a dummy page on your site with a full URL that is only accessible to the bots that Facebook and Google use. I'm not sure what Google's user agent is, but Facebook's is listed here:
https://developers.facebook.com/docs/reference/plugins/like/#scraperinfo
So you could have a blank page on /item/itemid1/ that is only accessible to the bots, point your og:url tags to that blank page and have the correct metadata on it for the Facebook scraper. Whenever a regular user tries to access it, redirect them back to the correct hash-based URL.
I created a FB App to facilitate FB Connect authentication on my website.
Users can share content from my site to Facebook via the same FB app.
We also created a FB Fan Page to grow our community reach.
However a FB App is a separate entity than a Fan Page, whatever content is shared via our website to FB the App link sends the users to an empty App page while all the fuzz is in our Fan page.
I did an extensive research for this issue and only came up with this useful post here in stackoverflow: "Fan page vs Application Page".
Ideally i'd want the App link ("... via appName") on every shared item to point to our fan page.
I need to know if this is an issue that FB needs to address, if i am missing something and what do you do to solve this situation
Some apps are able to do this :
http://mediafeedia.com/pro/
http://www.postplanner.com/white-label-facebook-app/
I also would be interested to know how they do this.
I've checked all app settings...
No, the App attribution on posts made via the API returns the user to that app's profile page - you'd need to have information there directing them back to your brand page if that's where you want them to go after they end up there.
I think in most cases people would click the name of the page or one of the links in the post rather than that small link at the bottom, no?