I made an application for Twitter, and it works. Now my friends want to use it as well. I placed the program at http://example.com/twitter/mytwitter.php.
Can everybody share the same consumer key or must each one fill out the Twitter request form, pointing to mytwitter.php and get his own consumer key?
A Twitter application has a single Consumer key/secret and Callback URL. If your app changes domains (which may happen if someone else uses your code for their app) then the Callback URL specified in your Twitter app settings (tied to your Consumer key/secret) will be wrong.
Each unique domain that the app is running on needs its own Twitter app profile with its own Consumer key/secret and Callback URL.
Related
When trying to create app requests through facbeook http graph api I'm getting the error "(#2) Failed to create any app request".
As described in the documentation (https://developers.facebook.com/docs/graph-api/reference/user/apprequests/) I'm using the URL https://graph.facebook.com/{userid}/apprequests setting in post the access token, a title and a message. I've tried different combinations of parameters just to check if I needed anything else, but just if I remove access token and/or title I get different errors.
In addition to that, if I use my own userid, instead of other userid (obviously a friend) that I want to send the request to, there's no error at all, but no request is created.
I don't think it may be related with permissions because both users (source and destination of the request) are admin, developer or tester of the app.
Thank you
Just in case anyone needs it, the problem is that user apprequests can only be created if using any facebook ui methods. That's why in this thread Apprequest of Android Facebook sdk 3.0 comment 1 advices to use webdialog instead of sending the request in code.
More on this topic, I've been researching and I found out that I started with my app really long ago (using API lower than 2.3) so I didn't need to set the category as "game" to be able to send apprequests. I updated its category and after multiple tests I've found the following scenarios:
Javascript API works correctly to send requests in my app
Graph API fails to send requests if using user auth token getting the same error as before
Graph API is able to send requests if using app auth token (from app_id + app_secret)
As far as I've read, there's no limitation in using either kind of auth tokens for apprequest calls.
In addition, my app will be running in web, desktop and mobile. The scenario in which I'm using graph API directly is desktop for obvious reasons (there's other APIs tor the other platforms). As recommended in the FB api documentation, the app secret should not be included in binary code deployed to users, so I would need to use the user auth token.
Any help would be apreciated
Thanks
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 writing an API for our product and I'm trying to understand how some basic OAuth works with regards to mobile apps that might leverage our (to be created) api.
Lets imagine that our website currently allows a person to LogIn to our site via Twitter OAuth.
On the callback from Twitter, our server retrieves the twitter OAuth result and if all good, then checks to see
if this user already exists in our DB (eg. lets assume the Email is the unique key). If they don't exist, we
create a new user.
Of course, we then log the user 'in', which means we create a cookie for them, for their browser.
So far - nothing new here. All normal stuff.
Now .. if we want to do this via an iPhone or Windows phone using their native language and the app's use our API, i'm not sure of the point where OAuth ends and our API takes over?
For example, lets pretend it's an iPhone app that takes advantage of our API.
The iPhone app will try to authenticate the user against their Twitter cred's. Ok, fine. But when it callsback, it's back in the phone, right? Not our servers. So then the app needs to try and create a new user? So then the iPhone might try and call /api/CreateAccount. But this means -anyone- can call this api? And how does the website really know they have authenticated? Only because the app says so? What's to stop the person from creating a malicious app and calling our API by flooding it with new account creations? And what about authentication to api resources? Forms Authentication isn't available here. So do people use querystring authentication over SSL for api calls? How does the iphone authenticate with -our- server?
I'm so confused.
Can anyone please explain the differences and common practices people are doing these days when they have a website and an api .. and use OAuth as the authentication mechanism, please?
The naive app would call not CreateAccount, but VerifyAccount with twitter's oauth set of data so you site and API could verify it. The site would respond with a unique userID and your iOS app would use that as it's internal user id. More info.
I'm working on an iPhone application which requires a user to login to Facebook. However that is only to retrieve a users friendslist, after that I wish to continue communication through my own XMPP server, I would like to automate the account creation to this server.
For this I would need a username, which is pretty straighforward: the facebook user id, however I would also need to create a password based on some sort of private key showing the user has logged in to Facebook. This key should be the same for any device logged in over any amount of time, I've been looking at the Facebook API but could only find an access token, which I believe is different when the user logs in from a different device.
My question: Is there anything available from the Facebook API with these requirements? Any suggestions for alternative solutions would be welcome too.
Thanks!
Edit:
Example:
User uses the app for the first time on his iPhone, logs in with facebook and the app automatically creates an acount on my XMPP server, where the user ID is equal to the facebook ID and the password is something that shows the user has been logged into his facebook account.
Now the user uses the app on his iPad, again logging into his facebook account, however already having an account on my XMPP server the same password must be generated from the data received from facebook.
Step 2 is the part which poses a problem for me, I need data that shows that the user has been logged into his account, and which is the same wherever and whenever he logs in, just so that the same password can be generated every time. I believe that if I use the access_token for this then this will change if the user for example doesn't log in for 60 days and starts using the app again, or maybe even when he logs into a different device?
To clarify: the XMPP server that Facebook offers is not to my needs, I need to be able to send other things besides chat messages and also need to be able to store messages so that new devices which log on can be synced to a proper state.
For Facebook XMPP, I recommend you to use the custom SASL mechanism called X-FACEBOOK-PLATFORM. Basically, the user must first log in to your application and grant the xmpp_login extended permission. Follow the client side flow to get a valid access_token for the user with the xmpp_login extended permission.
You send an base64 encoded string over TLS with the following parmeters:
string method: Should be the same as the method specified by the server.
string api_key: The application key associated with the calling application.
string access_token: The access_token obtained in the above step.
float call_id: The request's sequence number.
string v: This must be set to 1.0 to use this version of the API.
string format: Optional - Ignored.
string cnonce: Optional - Client-selected nonce. Ignored.
string nonce: Should be the same as the nonce specified by the server.
Your appID (api_key) can be use in multiple context and you'll be able to get the user access token for each of the user's devices.
Here is the Chat API doc: https://developers.facebook.com/docs/chat/
I want to build a Facebook application that will be available only to those who have been invited to it or to a certain list of people (the list will be used for initialization).
How can I achieve that?
Depends what you mean by available. Anyone can install/authorise your application - all it means is that it'll appear in their applications list, and that your application has more access to their profile.
However, whenever someone uses your application Facebook will send you their unique uid which you can then filter on within your own code. Store a list of uids that you consider "invited", and only allow them access.
Probably the neatest way to do this is at the start of a session; the initial exchange between Facebook and your application involves Facebook sending your app a uid and authentication token, with which your app requests a session key - if you filter at that point and simply refuse to request a session key for any uid that's not on your list, you can programmatically restrict access.
There is so called "application sandbox mode". It is intended for development and testing though. But the meaning of this mode - you directly specify what users have access to your app(testers)