in my iPhone app, I implemented the Facebook API, to piggy back on their user identification.
Now, rather than polling Facebook every once in a while to see if the information of a logged in user has changed, I would like to use the 'User object subscriptions'. From this document I learned, that I have to create a Callback URL (done, and tested), and that my app needs to be Whitelisted.
On developers.facebook.com/apps/ I can't find a way to apply for being whitelisted, and Google doesn't seem to be my friend anymore.
I hope you are.
The docs are stating
...some of these objects may require your app to be whitelisted by Facebook for access.
Basic Realtime Updates should work without any whitelisting involved, at least they do so for myself.
Whitelisting your app is not always easy to do, as certain APIs are meant to be quite restricted at a developer level. You can find further information about whitelisting here if you have not already done so.
As far as whitelisting, in your case I believe it just a matter of your app settings and IP whitelisting, which you can find more information about here .
Related
I'm a bit confused, at first I requested for basic and public_content permissions because I believed thats how I can view both my own images and other peoples' images on the app i'm pushing to the appstore.
However Instagram declined and say I didn't need it and that I only needed basic login permissions to view images. Now images for my friends no longer show up and its not a code issue because I can still see my own images.
Can I get a clarification of basic vs public_content permissions and if I'm doing this wrong from someone who has gone through the instagram review process? I've consulted the documentation many times and it seems as if I need public_content permission and reviewed several times but they always give us basic permissions.
I'm going to document what I did instead.
So for each user who logins and approves of Instagram access (by logging in on Instagram in my app using a webView and giving me the access token) I store their access token on a database and everytime that user comes up I grab the user's access token to request for their most recent media.
However this is really just me playing around and I'm not sure if:
a) Instagram refreshes the access token
b) This is explicitly allowed by Instagram, think I saw on its guidelines that this might be not allowed behaviour
and thus will need clarification on those above points if anyone else has a clue but this current method works for now for those wondering.
I've recently had an app rejected due to the 17.2 clause
17.2: Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
My app requires users to create a user account before they are able to use the app. All data in the app is tied to a specific user. Rather then create a custom login, it seemed simple enough to get users to signup with Facebook for "one-click" account creation instead of having to fill out a new account form. So I used the Facebook Graph SDK for iOS to accomplish this. However, I did not use any other features from the Facebook SDK and as a result of doing so, my app was rejected. I have a couple of uncertainties I was hoping could be answered.
Can I just implement a custom create account without the risk of getting my app rejected? The custom create account will require fields such as a userName, email, and account passWord.
I read somewhere that in order for Apple to approve custom account creation, the app must have some sort of Privacy Policy. Is this true?
What would classify as a "significant" use of Facebook services to justify the use of Facebook authentication? Would using features such as Share to Facebook and Invite Friends be significant enough to use in the app to get approved?
I'm curious to know how others have solved this problem and any advice or tips would be appreciated.
Facebook is very annoying with this clause. It isn't about how you are using the Facebook SDK, it is about asking users to create an account via any means. You have to justify your features so that they are user-oriented. You can bend the world in your favor on how you do this, though.
For example, even though a feature seems to be completely okay if user doesn't register, you can argue, "for better user experiences, we calculate user's performance on these features, and associate it with the account."
Or, you can go about saying "although this seem to be not user-related, we use the gender information to serve correct content."
Privacy policy is a must. You definitely need that accessible through the app and through the App Store page.
While working to get our app accepted after it got rejected by the same clause, my team spent a whole day trying to relate every major feature to something such that an account was necessary. But the good news is, it got accepted!
On another note, Facebook friend invites are fine, but making users upload a profile picture and create their own contents also need to be explained. They will ask questions such as "who will be able to see these contents?"
It is a tedious process, but more of a, "provide information and I'll let you pass" kind of thing. Good luck!
Is there a way to make the Google+ Sign-In not request the user's "list of people you're connected to on Google+"?
My goal is to use the G+ sign in for authentication purposes today, and in the future also use it for social sharing functionality. As the owner/operator of the service requesting sign in I don't care who is in a user's circles.
Is it possible to remove the request for all of the people a user is connected with? Am I missing something with this? For example if I didn't request all of a user's connected people would the user no longer be able to share to them?
I'm aware of the Google OpenId sign in functionality, but it doesn't provide the functionality I'd like for the future.
Whenever you use the Google+ sign-in button, the scope plus.login is added. As such, it will request the "know who you are on Google+" and "List of people you are connected with". A few notes on this:
The user has control over which people they share with you so if they don't want to share this information, it's within their control.
If you're interested in the information in the future - using the existing connections people have is a great way to make your site better - the access will be available to you.
If you still feel you should be able to just request the user's profile, please add a star/feature request to the issue tracker here:
https://developers.google.com/+/
The more information regarding why you want to do this and the clearer your request explanation, the better!
Recently I just notice how Path, Pinterest, and the like change the way they authenticate their users. Currently it seems that they require us to create an account associated with Facebook or Twitter. I could not understand the reason behind this. Is there any security concern for them to make this move?
Why is simple authentication with Facebook and Twitter not enough?
I think it is about giving the site more control over their future and the relationship to their users.
If they have their own account system, but allow the users to link it to Facebook or Twitter, that link can later be changed if the relationship with those providers turns sour.
The big reason is that they don't have to take any risk with handling passwords, etc. which can get hacked. They are offloading the security of user accounts to bigger partners, so they don't have to worry about it.
Let's say I am making a sign up form in which I asked user's twitter ID. How do I verify if the ID entered by user belongs to him/her? In case of verifying email we simply send a verification link which user has to click so how do I verify twitter ID? I have never used twitter before.
The only reliable and practical way to verify that twitter account X belongs to user Y this to do full on “3 legged” OAuth authentication. That being said, you may want to consider if you might be OK with just taking the user at their word on it.
Getting OAuth to work and securely storing the resulting tokens is much easier nowadays than it once was, but is still non-trivial.
Reasons to verify the twitter account, in increasing reasonableness:
You will be making enough server side requests, on behalf of multiple users, that you run up against Twitter’s API Rate Limiting. (Having multiple auth-tokens will allow for a higher API rate)
You need to automagically send tweets and/or follow accounts on the user’s behalf
N.B. do this as opt-in and be ultra clear about when/why you will be doing this, or you will face the justified fury of scorned users
Don’t verify the account if you’re looking to do these things:
You need to send tweets and/or follow accounts on the user’s behalf, and the user will be able to perform a browser based confirmation workflow for each of those actions; use Twitter’s Web Intents for this.
If you just want to pull in real time data for user’s avatar, bio, or recent Tweets Twitter supplies some prefab widgets for you.
All of the authenticated Twitter API Calls can be done client side with JavaScript. Twitter has a js framework, which does not require you to handle and store tokens on your server, to help you with that.
An alternate contact method for password resets, notifications, etc.
Private communication between users on twitter requires mutual following, many users probably never check their Direct Messages (or even know what a DM is), and any messages would be limited to 140 characters. Just use email for all that kind of nonsense.
If you’re just gathering this info to display it on a user’s profile page, in an “other places on the web” kind of way, integrating and maintaining all the server side OAuth pieces is likely too much bother. Just make sure you have a reasonable and clear TOS and an obvious way for 3rd parties to report any of your users who may be claiming a twitter account that is not their own.
If you’re still interested in OAuth, Twitter's Dev page has plenty of resources, including a nice overview of a generic “Sign In with Twitter” “3 legged” OAuth work flow.