I have an packaged app in the Chrome Web Store that I'd like to transition from a paid app to a free one with in app purchases. I need to be able to detect if the current user had paid for the app previously.
To be able to use the licensing API, I need the current user's OpenID URL. I was able to get this to work using chrome.identity and a popup dialog that the user has to authorize. But it is a bad experience and kind of a scary dialog.
For hosted apps, it's possible to get the user's OpenID URL without any user interaction or authorization. (see How to skip the OpenID approval screen). It would be fantastic if somebody knows how to make this work without user interaction for packaged apps.
I've detailed some of the approaches I've tried on this chromium-apps thread. I suspect it may be possible to do this with chrome.identity.launchWebAuthFlow but I wasn't able to discover the exact incantation of parameters to google's oauth/openid endpoints to make this happen silently.
I think you need to refer to this Link1 Parameters
this parameters are different techniques using that you can do this task..
also To bypass the Login/approval screen refer this link2
Here in the section How to skip the OpenID approval screen the details are explained which you can use..
And In case of packaged app this should ask for permanent permission that will help in OAuth throughout the life of app..
Client Library JavaScript Based
Authentication using Library
After your comment I thought this you can bind in your app.!!
Let me know what works for you..
Related
I have more than few clients that would like to add facebook connect to their landing pages (managed by me). They are too many and not enough tech-savvy to manually create ad appid for each of them.
So my only solution is to usa my own appid to add facebook connect to all my clients websites, but as far as I know, Facebook doesn't allow to simply use the same appid on any domain.
How can I solve this? I can't find any documentation to solve my issue. Does anyone have a direction for me?
This has been discussed a couple o’ times before already – but I mostly commented on earlier questions, so let me write the whole thing up as a proper answer, for future reference.
[paraphrased] Multiple-client Facebook login via one single app id
Does anyone have a direction for me?
You probably rather don’t want to do that.
It is not really possible to run one simple app one multiple different domains.
As a workaround for only a few domains, people used to specify different domains for the different platforms – Website, Page Tab or Canvas App, plus Mobile alternative for Canvas – without actually using any of those platforms besides Website, which made the app usable on multiple domains as a website app. But since Facebook introduced their login/permission review process¹, you can’t do that any more – they expect you to present actual functionality on all platforms you have configured in your app.
You can kind-off use one single app for login on multiple domains – if you are willing to use only the server-side login flow, and to redirect users to one “main” domain (that gets specified as the app domain in the app settings) to login, and then from there back to the origin domain.
But this has several drawbacks:
It’s not what you’d call a “white label” solution. If your clients expect it to look as if users where logging in via “their” app, it should stay on their domain. Individual branding, in regard to stuff such as app name, app logo that shows in the login dialog, etc., would also not be possible. Additionally, app attribution – the link that shows up under content shared/posted via the app – would only link users back to the main domain, and not to your customer’s.
You would not be able to use the JS SDK for client-side API requests, or even just to embed it to render any of the FB social plugins that require an app id – the SDK checks what domain it is “running on”, and can not be tricked to accept a domain that is not specified in the app settings.
There could be privacy issues. An over-exaggerated example: Just because I as the app user decided to share my photos or videos I have on Facebook with your customer Our-Holy-Mother-of-Christ-Bakery.com, does not necessarily mean I want to share them with your other customer, amateurs-doing-all-kinds-of-nasty-stuff.xxx as well – but if they shared an app id for login purposes, I automatically would. Have fun writin’ the Privacy Policy (which is mandatory if you use FB login functionality, and FB also automatically checks if your app has got one) for that scenario ;-)
Finally, and most importantly: All your customers would be “sitting in the same boat.” If one of them, or in turn their website users, would publish spam via your app id, so that Facebook blocks it, login would not work any more for all of your customer’s websites. And if you decide only then, that setting up an individual app for each of your customers would be the better way to go, they would not be able to recognize their existing users any more, because of user ids being app-scoped since API v2.0 was introduced – so if users logged into this new app, that app would see a totally different user id. (And to rely on an email address as an identifier is risky, too, because you will not get one from the API for every user; for example if they registered using their mobile device.)
Edit: Plus, app/domain insights, as luschn mentioned in his answer.
¹ Yes, the review process has made it more laborious to set up multiple apps for multiple clients. But for apps that do the same stuff/use the same permissions in the same manner, you can refer to an earlier successfully reviewed app id to speed up the process a little. Also, screenshots of how f.e. posts made via the app look on timeline, and what UI components are used, as well as screencasts that you include in your submission could probably be used with little to no alteration.
Apps are not meant be used on several different domains, you will have to create a new App for each domain, i´m afraid. You can use the different platforms in the App settings to use different domains, but there are only a few so it´s pointless. Just create some screenshots and a tutorial for your clients, that´s how it is usually done.
Btw, it would be weird to authorize an App on a website, and the same App would allow you to be authorized on all other client websites. Also, insights are per App, so your clients may want to see their own insights and not the global insights of all domains together.
Many is not defined but i think for being a smart developer you need to create new app_ids for every project you need to use facebook connect. Just my opinion. It also allows you to monitor alot of stuff.
As you can see on the image, spotify has a modified version of facebook login.
On the spotify app shown, user can login using either facebook or spotify account.
I wonder if its only on the looks or they were using other facebook authentication process.
I also wonder and worried if spotify could get facebook password entered by the user.
What facebook authentication they were using in here?
As you have noticed, Spotify is using a different Facebook login flow that is not listed anywhere in the official Facebook developer documentation. Since the Facebook password is entered into a closed source client, there is no way for you to know for sure what happens without heavy reverse engineering and debugging of the client. In that sense you should be worried. It goes against and devalues the good policy of "Please don't enter your password anywhere else". Thinking about differently, Facebook trusts this company enough to allow this. There might be a few more companies that have the ability to use this login flow, but I don't know.
I work at Spotify and was there when it was introduced (September 2011). We worked very closely with Facebook (I helped build some parts of the backend integration). It is not my favorite part of the client though. I would much prefer a standard Facebook OAuth 2 authorization flow. That was however one of the main technical problems in spring 2011 when we started to build this. We basically needed to embed a browser in the client to make it work properly or redirect the user to a browser and then back to the client again. There were also other reasons that I can't remember why we didn't do this.
Now when we have an embedded browser (since December 2011) it would be much easier to change. I believe this type of login flow will be phased out eventually.
How can I make a Facebook app that doesn't require users to log in/authorize my app? Is it even possible for canvas apps?
The conversion in auth dialog is quite poor (39%) for my app, even though I ask for the basic information only. Hence the question.
Thanks for advice!
There are no special actions necessary to run a canvas app in Facebook without authentication. Simply set the Canvas URL and Secure Canvas URL in your app's settings (https://developers.facebook.com/apps/<app_id>/summary) and it should just work.
Keep in mind that you cannot access any of the useful functionality Facebook offers if you forego authentication. You'll be missing out on:
The Invite Friends dialog
Creating notifications
Retrieving a user's friend list and information
Etc.
In fact, if you're not leveraging any of the available functionality Facebook provides, there's no sense in even creating a canvas app. You might as well enjoy the benefits of using the entire window for your application and host it standalone.
It all depends upon what you're doing with your app.
If you app uses features that requires login, then yes, you will need to get each user to log in.
If your app doesn't use features of the API that require login, then don't use it.
There's many social plugins that can accomplish a lot of what many people look for and most all of them don't require a login.
I've been trying to get this to work for a while, but I've apparently missed something.
All I want is to have the latest 3 or so posts from my clients Facebook page to populate and animate in a screensaver that I am building using Flash (AS3).
So far, every time I try to bring anything in, it requires a complete oAuth login and account link, but it's only a one way exchange (read-only, absolutely no writing, posting or even linking, since it's a screensaver) I'm not even sure the client wants pictures or anything.
I am currently trying to use the facebook-actionscript-api, but there isn't an option for the "App Login" type of Authentication that would solve most of my problems.
I'm at wits end and about to have to tell my client it can't be done. At least they'll always have twitter...
I don't think it is possible to get facebook feeds without an accesstoken (even if they are public). So I guess you need to define an app within Facebook and add login stuff to your app so users can give permission to your app for basic access.
Maybe this article offers some help: http://www.adobe.com/devnet/facebook/articles/flex_fbgraph_pt1.html
For a middleware system with internet (which works inside a set-top box) I want to develop a primitive Facebook interface where users can type their user-names and password, showing their latest notification, messages and other casual stuff on the TV screen by using the recent Facebook Graph API.
This middleware program uses Java ME to run programs (such as this simple facebook app) and it can connect to internet however it doesn't have a real web browser. Without browser it can connect to any url to retrieve the JSON response however I am not sure how to achieve authentication without a real browser.
Under this circumstances, is it possible Facebook authentication? If you think so, what approach would you suggest ?
Thanks
Facebook provides trusted partners with a private Authorization API to get an OAuth 2 token from a username / password.
A more complicated approach would be doing something similar to how Netflix enrolls a device:
device calls server to obtain a Code
device shows code on screen and directs user to go to URL on server and enter Code
server redirects user to Facebook and obtains OAuth token, user told to go back to device
device calls server with Code and obtains OAuth token
device can now make calls directly on behalf of user
According to this documentation on "Desktop Application Authentication" I don't believe your desired result is possible:
Facebook's OAuth implementation does not include explicit desktop application support. However, if your desktop application can embed a Web browser, you can add Facebook support to your application easily using the same OAuth User-Agent Flow used by JavaScript clients.
However, it is clearly possible for certain vendors to do this, since Microsoft's Xbox 360 Facebook application does exactly what you are proposing. I'd be interested to see if anyone has dug up any API for doing this that Facebook doesn't want in their most obvious documentation.
This isn't an answer but I'm trying to do the same thing. Check out this guy's blog which uses another server to proxy the requests:
cory wiles blog
If you figure it out please post a detailed answer here so I can do it to.. :)
I think it is possible though it is pretty complicated and subject to sudden changes of Facebook interface. It might break the agreement between you and Facebook.
What you do is to emulate the Facebook.
One path you have to set up a Facebook application. Once you got the authorisation from user, you can to something with Graph API.
You need to the Facebook log-in process and authorisation process. There are some capturing tools on http/https request and response. Analyse them, both header and body.
Once you know the authorisation mechanism, you can replace it with you own. Everything afterward is on Graph API.
Another path is to emulate Facebook login and message and notification process. Capturing and analysis is needed.
In the past I have used a tool called screen-scraper (full disclosure: I used to work there) to automate logging in to facebook. Basically, it imitates a browser session; it allows you to set session variables (i.e. username, password) which would then be submitted to facebook, just as if the user had submitted them in a browser.
You may not be able to use screen-scraper in your set-top box environment (although it is java-based, so it's possible it would work). Even if it doesn't, you could implement a similar strategy in java, making the HTTP calls a browser would make to load the login page and submit the user's credentials. To keep the user's info safe make sure whatever HTTP client library you use supports HTTPS.
Proxy tools and extensions like Charles, Fiddler2, Firebug, Chrome's dev tools, etc. are helpful in seeing exactly what the browser is sending to the server in requests.