For some time now I try to figure out how these guys were able to add "Sign online here" button which is "install App" button on their fan-page tab:
http://www.facebook.com/GuinnessIreland?v=app_165491161181
I've read around the web and couldn't come up with any solid solution. The FBML and FBJS documentation left me with nothing.
So please, if anyone can help me with this.
NOTE: To make multiple tests on the Ajax request that are sent, do not accept the App install. It behaves differently after that.
I had some problems with finding out about it as well. There is no info about this kind of behavior in wiki or anywhere. I got it working after trying some possible solutions and the simplest one is to make user interact with content embedded in fan page tab such as click on something etc. Then you need to post an ajax request with requirelogin parameter to pop up to come out. The simple example would be:
user_ajax = function() {
var ajax = new Ajax();
ajax.responseType = Ajax.RAW;
ajax.requireLogin = true;
ajax.ondone = function(data) {
new Dialog(Dialog.DIALOG_POP).showMessage('Status', data, button_confirm = 'Okay');
}
var url = "http://yourappurl.com/request_handler"
ajax.post(url);
}
And the trigger for it:
Interaction
Then if user is known to be using your application (fan page tab) you can prompt him for additional permission like publish stream or email communication by calling:
Facebook.showPermissionDialog('publish_stream,email');
Hope this solves the problem.
Related
I am trying to add a prompt link to my Google Action:
https://developers.google.com/assistant/conversational/reference/rest/v1/TopLevel/fulfill#link
My response looks like this:
payload.prompt.link = {
name: 'Open My Website',
open: {
url: 'https://mywebsite.com'
}
}
When testing on my Nest Hub, the link does show as a suggestion on the bottom of the page. However, when I click on it, it simply sends it as an utterance to my Action instead of open the web page.
Any idea why this is happening? And what is the expected behavior for prompt links? I cannot find much documentation on them.
This appears to be the Actions Builder implementation of Link-Out Suggestions, which were not originally available when the Actions Builder was released. They were, however, available for Dialogflow previously.
Link-Out Suggestions require the "WEB_LINK" device capability to work. Smart Displays do not have this device capability.
I'm about to submit my latest app/game, and it seems something changed, since my call to Facebook's showDialog only works half way.
This is the structure I'm using to make the call which worked fine a month ago when I last tested it:
local fb_publish_properties = {};
fb_publish_properties["iTunes"] = {};
fb_publish_properties["iTunes"]["text"] = "Blabla text to be shown";
fb_publish_properties["iTunes"]["href"] = "https://The link to open on text click";
fb_publish_properties["GooglePlay"] = {};
fb_publish_properties["GooglePlay"]["text"] = "Blabla text to be shown";
fb_publish_properties["GooglePlay"]["href"] = "https://The link to open on text click";
local fb_publish_properties2 = json.encode(fb_publish_properties);
local fb_publish_params = {
app_id = facebook_appId,
from = user_fb_id,
to = user_fb_id,
picture = "http://icon picture here",
name = "Title of post",
caption = "Come play against me!!",
description = "",
properties = fb_publish_properties2;
}
facebook.showDialog("feed",fb_publish_params);
Now, as I said, this worked just fine a month ago, but now, it posts the post to the feed alright, but nothing of the properties is shown in the post, and while clicking on the post itself, it leads to the message icon (which I believe happens since he doesn't recognized any other links in the message).
First, what is wrong with Facebook, changing their API every 2 months!!?? but now really, what is wrong with the piece of code which used to work but now works only partly?
Thanks all!
UPDATE:
After not doing anything about it, just going on as normal, some of the things started working on their own, for example, now when the Facebook API opens on the device (iOs or Android) I see the texts just fine as they are supposed to be, yet when I publish to stream, the post that shows online again, shows only the caption text, not the properties texts and links, and when I click on my post online, it leads to the icon file I'm using and not to the links I've published.
This is the last thing that stops me from publishing this app, please, someone, help??!
This is not an answer, but does not fit in a comment:
Try the following to see if you get anything at all:
facebook.showDialog( "feed", {link="http://www.coronasdk.com/"} )
facebook.showDialog( "apprequests", {message="some message"} )
Please update your post accordingly, describing what you observe, then I can then erase this. Also ensure that login succeeded (the fbconnect event properties of didComplete, isError and expiration).
I have an HTML5 application that uses Azure mobile services authentication to login (straight from the example code...provided below). It works fine in all desktop browsers and iPhone 5 in Safari. But from app / full screen mode, it does nothing (doesn't ask for permission to show a popup window like it does in safari and no popup windows shows up) and I can wait forever and nothing happens. If I invoke it a second time, it gives an error saying "Error: Unexpected failure"...perhaps because the 1st attempt is still running? Any help/insight is appreciated.
client.login ("facebook").done(function (results) {
alert("You are now logged in as: " + results.userId);
}, function (err) {
alert("Error: " + err);
});
edited update with more info and 2 potential ideas*
I did some more research and found a site that uses an approach that overcomes this problem and also solves two other side effects with the current Azure mobile approach to authentication. I think the Azure mobile team might be looking to do something similar because there are some hints of other authentication options in the code (although difficult to read and be sure because the minimized code is obsfucated). It might be just a matter of activating these in the code...
The "solution":
Go to http://m.bcwars.com/ and click on the Facebook login. You'll see it works perfectly in iPhone Safari in "app mode" becuase instead of doing a popup, it simply stays in the current browser window.
This approach solves two other problems with the current Azure mobile approach. First, the popup gets interpreted by most browsers as a potential ad and is either blocked automatically (desktop Chrome) ... and the user doesn't know why it's not working...or gives a warning which the user has to approve (iPhone Safari in "browser mode") which is a hassle. And if the user has a popup blocker, it gets more difficult and even more potential for the user not getting it to work properly. The bcwars.com method doesn't have this problem.
Second, in iPhone Safari, when the popup window auto closes, the original page doesn't get focus if there are other browser windows open in Safari. Instead, it's in the smaller/slide mode so they can choose which one to show. If this happens, the user has to go through one more sttep...click on the browser window to activate it and give it focus..again more of a pain and more potential for them to mess up and not do it correctly and need help. The m.bcwars.com doesn't have this problem.
Azure options:
Looking at the Azure mobile code it looks like may already have the solution. I can't read it easliy becuase it's minified/obsfucated, but it seems to have 4 options (including iFrame, etc.) for invoking the authentication, and only 1 (the "less ideal one" of a popup) is being used. An easy solution would be to set a property to allow one of the alternate authentications to work. But I can't read it well enough to figure it out. Another would be to hack the code (temporarily until a fix is put up by Microsoft).
Could I get some help there perhaps?
You can implement an authentication flow with Facebook that doesn't use a popup. The basic idea is to use the 'Web Flow' for doing the login, and once the window return from the login, use the access token to login the user in to Azure Mobile Services.
The Facebook documentation for doing this is here:
https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/#step2
Some code samples to make it easier for you.
You would start by something like this:
(Remember to replace YOUR_APP_ID and YOUR_URL with something relevant to your site.
function logIn() {
window.location.replace('https://www.facebook.com/dialog/oauth?client_id=YOUR_APP_ID&redirect_uri=http%3A%2F%2FYOUR_URL&response_type=token')
}
This redirects the window to the Facebook page for the user to log in and authorize your app. When the user is done, Facebook will redirect the user back to YOUR_URL given above.
There you can handle the redirect and do the Mobile Services Login with something like this:
function handleLoginResponse() {
var frag = $.deparam.fragment();
if (frag.hasOwnProperty("access_token")) {
client.login("facebook", { access_token: frag.access_token }).then(function () {
// you're logged in
}, function (error) {
alert(error);
});
}
}
In here you parse the access token you get as a URL fragment and pass it as argument to the login call you make to Azure Mobile Services.
This code depends on the jquery BBQ plugin to handle the URL fragment easily.
Hope this solves your problem!
So Intuit charges for each active connections to QuickBooks. Therefore, I want to restrict the QuickBooks functionality in my application to premium users only.
Ideally when any user clicks the "Connect to QuickBooks" button and my RequestOAuthToken http handler is called, I want to check if the user is allowed to use QuickBooks. If that is the case, then the normal OAuth flow continue. If the user is NOT allowed, then I want to redirect the user to the upgrade page of my app.
Given that the "Connect to QuickBooks" button opens a new window (at least on desktop, I haven't tried on phone/tablets), the window should get closed, and the main window (my app) should redirect the user to the right page. And actually this is exactly what happens if the normal OAuth flow completes.
Now, I have tried a few different approaches but I couldn't get it working.
1) In my RequestOAuthToken, return a HTTP redirect to the plan page
2) In my RequestOAuthToken, return an html page with javascript logic to redirect to page
3) In my RequestOAuthToken, return HTTP redirect to a page with javascript logic to redirect to page
4) I haven't tried that one but could I somehow intercept the javascript click handler on the Intuit button. I'm not sure if that is an accepted practice.
Here is the piece a javascript I grabbed from the .Net sample:
try
{
var parentlocation = window.parent.opener.location.hostname;
var currentlocation = window.location.hostname;
if (parentlocation != currentlocation)
{
window.location = plansUrl;
}
else
{
window.opener.location.href = window.opener.location.href;
window.close();
}
}
catch (e)
{
window.location = plansUrl;
}
Help me out please.
I don't think you'll be able to do exactly what you're asking, but you can probably come close by taking a different approach.
Rather than trying to redirect them after they click the button, why not try to redirect them before they click it? e.g. when they try to get to the page that has the "Connect to QuickBooks" button it, check if they are a premium user there, and redirect them if they are not.
I don't think you'll be able to redirect them after they click the button because once they click that button, they get kicked over to Intuit's website and it's beyond your control at that point.
Clement, Keith has provided the answer we would want you to pursue. You may not alter the behavior of the Connect To QuickBooks button. It must be used as described in our documentation. Providing a link to a page that shows the Connect To QuickBooks buttons for your premium users and an upgrade message to non-premium users is the way to go.
I highly recommend that you visit http://docs.developer.intuit.com/0025_Intuit_Anywhere/0010_Getting_Started/0040_Publishing_Your_App and review all of the documentation there. If you develop with our guidelines and requirements in mind it will speed up the review process.
Tony Purmal
Developer Relations Engineer
Intuit Partner Platform
I have a Facebook app that is built as an iFrame. I am using the JavaScript client API loaded via:
http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php
In my initialization code, I use the requireLogin method to ensure that the user has authorized the app. I have found this to be necessary to be able to gather the user's name, avatar, etc. for the scoreboard. Here's a representative code snippet:
FB_RequireFeatures(["Connect","Api"], function() {
FB.Facebook.init("...API_KEY_HERE...", "xd_receiver.htm");
var api = FB.Facebook.apiClient;
api.requireLogin(function() {
api.users_getInfo(
FB.Connect.get_loggedInUser(),
["name", "pic_square", "profile_url"],
function(users, ex) {
/* use the data here */
});
});
});
This causes the iframe to redirect causing the Facebook authorization screen to load within my app's iFrame. This looks junky and is somewhat confusing to the user, e.g. there are two Facebook bars, etc.
Question 1: is there anything I can do to clean this up while still implementing as an iFrame, and still using the JavaScript APIs?
According to the FB API documentation:
FB.ApiClient.requireLogin
This method is deprecated - use
FB.Connect.requireSession instead.
My experience though when I replace api.requireLogin with FB.Connect.requireSession it never gets invoked. I'd prefer the recommended way of doing it but I struggled and was not able to find a way to get it to work. I tried adding various arguments for the other two parameters as well with seemingly no effect. My expectation is that this method will load in a dialog box inside my app iFrame with a similar authorization message.
Question 2: what am I missing with getting FB.Connect.requireSession to properly prompt the user for authorization?
Finally, at the end of the game, the app prompts the user for the ability to publish their score to their stream via FB.Connect.streamPublish. Which leads me to...
Question 3: am I loading the correct features? Do I need both "Api" and "Connect"? Am I missing any others?
Here is a summary of the changes I needed to make to clean up the authorization process. It appears that iFrames must fully redirect to properly authorize. I tried using the FBConnect authorization but it was a strange experience of popup windows and FBConnect buttons.
Ultimately this game me the expected experience that I've seen with other FB apps:
FB_RequireFeatures(["Connect","Api"], function() {
var apiKey = "...",
canvasUrl = "http://apps.facebook.com/...";
function authRedirect() {
// need to break out of iFrame
window.top.location.href = "http://www.facebook.com/login.php?v=1.0&api_key="+encodeURIComponent(apiKey)+"&next="+encodeURIComponent(canvasUrl)+"&canvas=";
}
FB.Facebook.init(apiKey, "xd_receiver.htm");
FB.ensureInit(function() {
FB.Connect.ifUserConnected(
function() {
var uid = FB.Connect.get_loggedInUser();
if (!uid) {
authRedirect();
return;
}
FB.Facebook.apiClient.users_getInfo(
uid,
["name", "pic_square", "profile_url"],
function(users, ex) {
/* user the data here */
});
},
authRedirect);
});
For iFrames, the solution was ultimately to redirect to the login URL which becomes the authorization URL if they are not already logged in.
I think that FB.requireSession only works from a FB connect site outside of
Facebook. If you're using an app hosted on apps.facebook.com use the php api
call instead,
$facebook = new Facebook($appapikey, $appsecret);
$facebook->require_login();
or link to the login page.
Of these methods to login
* Using the PHP client library
* Directing users to login.php
* Including the requirelogin attribute in a link or form
* Using FBML
only the first 2 are available to iframe apps hosted on apps.facebook.com
I think requirelogin and fbml only work with fbml canvas apps.
see
http://wiki.developers.facebook.com/index.php/Authorization_and_Authentication_for_Canvas_Page_Applications_on_Facebook
Question 1: is there anything I can do
to clean this up while still
implementing as an iFrame, and still
using the JavaScript APIs?
Question 2: what am I missing with
getting FB.Connect.requireSession to
properly prompt the user for
authorization?
Please have a look at this. This article discusses correct use of require session and provides links on how to implement that. And yes, you are right, the requireLogin has been deprecated and won't help any more.
Question 3: am I loading the correct
features? Do I need both "Api" and
"Connect"? Am I missing any others?
As far as I know, you can use both API and Connect together, basically you access Facebook's API with the help of JavaScript.
For iframe apps however, there is no great help and minimum support of API with some handful functionality available. See this for more info.
This causes the iframe to redirect
causing the Facebook authorization
screen to load within my app's iFrame.
This looks junky and is somewhat
confusing to the user, e.g. there are
two Facebook bars, etc.
Finally and personally I have not seen any iframe app requiring user to add the app first. This will create the problem of two bars you mentioned as quoted above.
The link I posted at the beginning of my answer has some useful links to get you started and decide the next-steps or possibly making changes to your apps.