We're trying to use the Facebook Authenticated Referrals feature on our website.
Right now it works fine when one user (Alice) uses a Feed Dialog to post to her wall and another user (Bob) clicks on Alice's post. Bob sees an Auth Dialog before navigating to our website.
But our app doesn't (currently) use Feed Dialogs; we just have Like buttons everywhere. I was hoping/expecting that when Alice clicks the Like button in an article on our site, and Bob clicks on Alice's "Like" post, Bob would get an Auth Dialog.
Am I just misconfiguring my site/app somehow? Is it possible to get Authenticated Referrals from Likes at all?
I didn't realise this was potentially possible - I assumed it would work if the liked URLs were all http://apps.facebook.com/{YOUR NAMESPACE}/ URLs - if this isn't working it sounds like either a bug or a fairly reasonable feature request.
If the likes are to URLs outside of your Canvas URL I wouldn't really expect this to work, because the links are not definitely associated with your canvas app
«If you need access to more information, such as the user's email address, etc. you must request permissions for this information. If you can do this by adding the permissions you need to the scope attribute of the Login Button like below»
http://developers.facebook.com/docs/guides/web/
Check the link, I've waste enough time but still not understand, why should we ask grant permission for our application twice — in App Settings first and <div class="fb-login-button" data-scope="read_stram, offline_access"> here is the second one. Just check your data-scope attribute.
<fb:login-button> attribute is scope, you can read a bit about it by the link below.
http://developers.facebook.com/docs/reference/plugins/login/
In a Facebook bug, a FB engineer responded to say: "this is currently the design of authenticated referrals. It only happens with Open Graph app publishes."
So, at least for now, no authenticated referrals are possible for Facebook Like links.
Related
I have a "Sign in with Google+" button on my page. When people click on it, I want the only thing they authorize to be "View your email address."
I don't want "Know who you are on Google" or "View basic information about your account." I only want their email address.
I'm playing on the OAuth 2.0 Playground (https://developers.google.com/oauthplayground/) and see this:
Scope: email
Requests:
Know who you are on Google
View your email address
Scope: https://www.googleapis.com/auth/userinfo.email (and this one is deprecated)
Requests:
Know who you are on Google
View your email address
Indeed, I've noticed that too. And I found an explanation from February 2013 here:
This is an intentional change to more precisely communicate to users the set of permissions that is being granted. Through knowledge of the user's email address it is possible, via indirect means, to locate the user's profile address. In the interest of more accurate disclosure, thus, we are prompting users to approve such disclosure.
Not exactly what you want, but combining profile and email will at least give one a less scary description for the first:
This app would like to:
View basic information about your account
View your email address
...with the help for the first saying:
More info
View your name, public profile URL, and photo
View your gender
View your country, language, and timezone
To me, this feels better than the vague This app is requesting permission to associate you with your public Google profile which one gets as the More Info for Know who you are on Google+, when not explicitly using scope profile, or when using scope openid.
As an aside: LinkedIn's OAuth 2 also always needs a user to grant access to Your Profile Overview, even if an application only needs some unique identifier. Other than with Google's explanation in Owen's answer, I assume LinkedIn really wants developers to use their network features.
I'm working on an internal website for the company I work for. The website will be only available to company staff. We use Google Apps for Business, so we would like authentication to be done using our google accounts.
I've gone through 'google sign in' samples from here: https://developers.google.com/+/
It works, but the problem we run into is that it requires the user to sign up to Google+. This is a speed bump we would prefer not to have.
Are there any ways around this? Thanks.
It shouldn't be too hard to roll your own sign in using the lower levels of Oauth, eg 'email' scope. It's hard to give a more specific answer because it depends on your architecture (eg. are you predominantly server-side or client-side) and what kind of session do you want to create by the sign in process. For example, if you are client/REST based, you probably don't want any session at all as REST encourages statelessness. On the other hand, if you are more web based, serving static pages, you will want a session.
In simple terms, you will be doing something that generates an access token, and then processing that access token to determine the email address (or Google ID) of the person who created it. You will then establish some sort of session (eg. using session cookies) that identifies future requests from that user.
Feel free to add some more detail to your architecture and I'll try to finesse the answer.
For simple http servlet sessions, it will be something like.
User requests a protected page
servlet detects that there is no session and/or session has no authenticated user
servlet redirects to an Oauth page to request an access code. something like
https://accounts.google.com/o/oauth2/auth?redirect_uri=xxx&response_type=code&client_id=zz&approval_prompt=auto&scope=email
NB research the exact URL, don't rely on this to be exact
If the user isn't logged on, he'll be prompted; if he has multiple logins, he'll be prompted; if he hasn't yet granted email access, he'll be prompted. If none of these conditions are met (the normal case) he won't see anything.
Browser will redirect to the redirect_uri, carrying an access token (or an auth code if this is the first time the user has used the app)
Post the token to the Google userinfo endpoint, and you will receive a decode containing the email address
Store the email into a session object (or retrieve your own user object and store that)
redirect back to the originally requested page. You can use the OAuth state parameter to pass that around
et voila. all future page requests from that user will be within a session containing some user identification.
NB This is just an outline and I may even have missed a step. You will still need to do your own OAuth research.
Apparently not:
(..) if a Google user who has not upgraded to a Google+ account clicks
on the Sign in with Google+ button, the same consent dialog that opens
will take the user into an account upgrade flow.
Weirdly the docs for OAuth2 states:
Google+ Sign-In works for all users with a Google account, whether or
not they have upgraded to Google+.
So when you put the login button plugin on an app it seems to display the user's friends that are using said app. It displays this even to users that have NOT allowed the app access yet. For example, if you go to "Henry's Cooking App" but have never Logged into the app thru facebook, it will still show you your friends that are using the app.
What I'm trying to do is use this feature to grab an array of fb-userids from the plugin so I can do a query on my DB to show the POTENTIAL user a little more info. For example let's say you have 2 friends that already use "Henry's Cooking App": Joe and Karen. If I could get their userid I could then show you something like "Joe just cooked Veal Scallopini, and Karen is perfecting her Tonkatsu Curry".
I know you could do this easily IF you had the authentication token, but that is only obtained after the user logs in. I'm trying to leverage the fact that fb seems to think it's OK to show your friends that are using the app BEFORE you sign up for the app.
The only super hacky way I could think of to do it is the fact that I could pull the href attribute of elements matching $(".uiFacePileItem a") which gives a link to the user profile which I could then grab the username or UID from. This seems like it could break easily though, anyone have a better idea? Thanks!
The only super hacky way I could think of to do it is the fact that I could pull the href attribute of elements matching $(".uiFacePileItem a") which gives a link to the user profile which I could then grab the username or UID from.
You can’t do that, because the Facebook login dialogs are not running under your domain – so the Same Origin Policy prevents you from interacting with the DOM of these dialogs.
I'm trying to leverage the fact that fb seems to think it's OK to show your friends that are using the app BEFORE you sign up for the app.
Well, it’s certainly (more) OK if Facebook does that – because that doesn’t give any information away to third parties (meaning you as the app developer/provider) – only the user sees that.
It would not be OK if Facebook would let you access this info, at a point where I haven’t even decided to use your app yet – totally a case of „none of your business”.
After I decide to use your app, you may have access to certain information. Before that – No Way, José.
Is there a way to test whether a user is logged into Flattr?
The idea is to set up a "I'm-ready-to-donate-wall" that only Flattr users are allowed to pass. However, unlike a paywall, the user is not forced to click a flattr button; I just want to make sure that he's ready to flattr anything if he/she likes what he/she sees. I am not interested in his/her account credentials either.
Obviously, this is a thinly veiled scheme to get users to sign up to Flattr. I don't know whether this is a good or bad idea, but it might be worth a shot.
"The idea is to set up a "I'm-ready-to-donate-wall" that only Flattr users are allowed to pass."
Beware that, if I remember correctly, it was not accepted in the Flattr code of conduct. Maybe it has changed lately (I cannot find the reference of this) but check first with some Flattr people if you can legally do that.
You can use "login" to your site with the Flattr OAUTH 2 API.
So what you would do is to connect your site as an third part application to flattr and then let the users authenticate with their Flattr login
http://developers.flattr.net/v2/#authorization
The first time the users access use your site they have to allow your app access to their Flattr profile.
Moreover, you can authorize a user without gaining access to any non-public features. To get any special access you need to specify the scopes for which you want special access - specify no scopes and the only thing you get to know is that a specific user has a specific account on Flattr.com.
I'm trying to add a "share via twitter" link to our website. I'm aware of the standard http://twitter.com/home?status=TWEET method, and it works good enough for my purposes when the user is logged in to twitter already.
If, however, the user is not logged in, twitter displays the login form first (which is only reasonable). After the login, the home screen is displayed without the tweet content.
Am I missing something obvious, or is this a know flaw in this method? If so, what is the easiest way (apart from using services like TweetMeme, which I noticed asks for login in advance) to make the share button work as expected?
If the user is not signed in when accessing http://twitter.com/home?status=TWEET it seems that the status is indeed forgotten. This would be a Twitter website issue and not something you're doing wrong.
Update: Use this URL instead: http://twitter.com/intent/tweet?text=TWEET
TweetMeme, on the other hand, uses its own Twitter "application" via the OAuth authentication, requiring users to log in before retweeting using TweetMeme, and is smart enough to include the tweet message in the OAuth callback URL so that it's not forgotten.
So really, you can:
Use TweetMeme, where the user would have to log in, but at least have the tweet be remembered once that's done;
Create your own Twitter application that uses the same tweeting functionality as TweetMeme; or
Use Twitter.com's less-than-desirable status updater and hope the user is logged in, or hope that they're smart enough to click the back button a couple times and click on your link again if needed.
Just use the following url and parameters
http://twitter.com/share?text=YOUR-TEXT&url=YOUR-URL
Then it works.