I recently had to integrate Facebook authentication into an existing application, having its own notion of a User. I created a separate class, called FacebookAccount, which is connected to a particular user within my system.
I was initially saving the access tokens, and checking against them, rather than the Facebook id. Then, I realized by accident how unreliable access tokens actually are. They change over time, while the Facebook id is supposed to always stays the same.
Here comes the question - should I even care about storing the access tokens? If they are really transient, like, some sort of session ids, changing every now and, it makes no sense to store them at all, right? All I need would be the Facebook id. I will simply keep the access token in the browser session
You can use it for offline access if needed. Some applications (especially mobile) require Facebook login even when offline (Spotify for example.) They probably store the token and expiration date and allow you to use the app even if you are not connected to internet.
In your case, it might make sense to store it and replace old token with new one once it's acquired, just so you can re-use the API and have it passed from the database.
Related
I want to integrate my application with Soundcloud for having the user statistics and so on, I use the client.authorize_url to send the user to approve the app on Soundcloud and I get the proper access_token but I want to know how to correlate between this access_token t the user that clicked on the client.authorize_url in my backend database (I mean I get the access token but how do I know to save it in the DB for the right user?)
Note: not a soundcloud dev.
There are two possible questions being asked here and I'm not sure really what you are asking.
If you are asking about storing data pertaining to a user that has connected through your app: Why do you need to store access tokens on your database? Access tokens expire, and they will change over time, even if it is the same user. It is better to store user-specific data (if needed at all) to a database referencing the users ID. That specific ID will not change. If you are talking about
If you are asking about the app itself, and how to reference that users information once they connect: This is done by using the method call on the SDK (not 100% on the name as I use custom implementations) for Me(). Check the documentation for more info. Hopefully this helps - if you needs some clarification let me know.
I've got a web app that currently allows users to login via Facebook. This is the only login mechanism at present. I make use of the user id and the users friends to perform certain actions. Now I want to create an api that I can use to create a native mobile app. To do this, I would need to authenticate users against the api. I've looked at this question
Possible approach to secure a Rest API endpoints using Facebook OAuth
but I don't actually have a "user" table as I only pull the facebook info when I need it. In iOS or something similar I could obviously make use of the native facebook sdk and then call my api, passing in the required user id and friend ids etc. however I'm not sure then how I could specifically secure my api so that if a user got hold of another's user_id they could in theory retrieve info via the api or in theory any resource that only specific users should be able to see
I thought about creating an app_id and app_secret for all the separate apps consuming the api. I would then use the appropriate secret to encrypt the data being sent and returned. The api and native app would know the secret and be able to decrypt it and validate that a user can view the requested resource. Does this sounds like a valid approach? In theory only the native apps would then be able to decrypt what is returned from the api. Or should this really be done on a user by user basis as recommended in the linked post?
All of this would be done over https
Thanks
Not familiar with the Facebook API nor iOS so I am speaking completely in theoretical terms.
Could you not:
Ask the user to login with Facebook on the iOS app
Send the login data over a secure channel to your web application to handle the actual processing of the data
Send the iOS app a secure hash for authentication
Use your web application as needed; using the hash for authentication, make HTTPS requests as you would your web application and use the responses from the webserver to populate the iOS app
If you make a user_hash column a complex salted hash like a SHA-256 (or greater) hash, the user_hash will become invalid before anybody is able to guess the hash. You could save the user's Facebook credentials locally on the iOS device and then renew the hash every so often, as to invalidate old hashes and lock out perpetrators (like how a cookie expires). If the user hash somehow becomes invalidated while using the iOS app, the app will send the locally stored credentials and retrieve a new one.
If Apple offers cookies for apps, you could send the hash in a cookie from your webpage and give it a reasonable expiry time (e.g. 1 day). You'd be resending the locally stored Facebook credentials every day and be effectively locking out anybody trying to bruteforce your hashes. Use that instead of trying to implement cookies from scratch (if the iOS API offers that), but as I said, I'm unfamiliar with iOS.
From an SQL standpoint, your webpage would validate a user's Facebook credentials, create a new row with a randomly generated user_hash, expires timestamp, user_id, friends_id, etc. Every user that uses the webpage will have to send the user_hash either from their web-client or the iOS app and will be checked against the database. If the present timestamp exceeds the expires timestamp, the session is ruled invalid and the user cannot operate your application.
Of course, you'd need to encrypt the communication. Do you pass credentials everytime the user loads a page on your web app? Or do you store them in a session?
Hope this helps at least somewhat!
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSHTTPCookieStorage_Class/Reference/Reference.html
I'm trying to figure out a core concept in FB that even after reading a lot of FB documentation, couldn't understand.
Let's say I'm building an app (that will reside in a tab), in which I want to see the last post of a user. I want to do this approximately one month after the user approved my app, without him using the app again.
I assume I will need to use a long-lived expiration token that will be saved to my DB.
A month after I will run a procedure that will use this token and check the user posts.
Is this correct?
What about a situation in which the user logged out? The token is no longer valid.. does this mean I will never be able to access user posts unless he will access my app?
Isn't this a bit weird (since he already approved my app)?
Not necessarily.
Firstly, you need the read_stream permission from the user when they authenticate your app. Then, because you are intending to use Facebook as the app, rather than as the user, you need to authenticate as an app, which is a simple process:
In order to get an access token for the app, all you need to do is use the following URL:
https://graph.facebook.com/oauth/access_token?client_id=YOUR_APP_ID&client_secret=YOUR_APP_SECRET&grant_type=client_credentials
Because these tokens are time-limited, it may be easier to request a token each time you use the Graph API, rather than storing it in a database and waiting for it to expire.
Then, all you need to do is use the following request:
https://graph.facebook.com/USER_ID/feed?access_token=YOUR_ACCESS_TOKEN
The upside to this is that it does not matter whether or not the user is logged into Facebook.
See here for more details:
https://developers.facebook.com/docs/authentication/applications/
My scenario is somewhat like this: A user logs into my website with his FB credentials. I capture his ID and the FB access token (say, a long-lived access token). He exits my website, and returns back later. However, this time, his browser has FB open with a different ID. Would I be able to load facebook details of this old id (with which he had registered on my site) using the stored access tokens? Is it possible, or would it result in a clash between the old and the existing FB id?
Correct me if I'm wrong, but he/she should stay logged into your website, regaurdless if his authID changes.
First of all, why would you want to do that? Since Facebook does not allow multiple user accounts for one and the same person, the only case where this would normally come into play is when another user is using my computer/browser – and why would I want you to read my info while that other person is using my device …?
Second of all, as long as the first user is still considered logged in to your site, it makes not much difference. But lets say some client-side method is called that updates the cookie information, then that’s where trouble might start. You might still be able to read the old user’s info, since you have his valid access token – but you’d have to use that token in your requests explicitly, and also address the account specifically, since the Graph API’s /me would point to the new user.
But as I said, I can hardly imagine a real, practical use case here …
I want to be able to occasionally programmatically grab some data from the graph API using python that is already accessible to my own FB account. Almost all of what I want is public, so is easy, but a couple Pages, although for large-scale brands, happen to be restricted to logged in users. These are accessible when using an access token (including the example one on the doc page).
I've read that what I need for this is an offline access token so that it won't expire. However, in trying to go through creating one, by first creating an app, it's now asking for credit card or phone verification.
Is there any (allowed) way to get an offline access token without this step? I don't even want to create an app in the first place. I just need a token to pass in with my https://graph.facebook.com/PAGENAME? queries.
thx
There isn't, as far as I know. The verification part is needed for you to access the developer tools and without them you cannot create a new app (the first solution) or use the Graph Explorer to generate an offline_access token.
You could make someone who has a verified account an admin to your pages and then use his access_token, but you would have to keep him as a permanent admin for the token to keep working, so I don't really think you would want that.
Just verify your account. Mine went really smoothly, they simply sent me an sms, no charges for me to pay, I entered the code and that was it