So I'm building this app for a client (It's a basic scheduling app like HootSuite but simpler) and he wants the ability to add multiple Facebook accounts with an IAP (aka In-App Purchase) after said IAP is purchased. The IAP is all done and works great but I cannot figure out how to link multiple Facebook accounts. I tried to use the same login method that a previous developer used (It's an ongoing freelance project and 2 other devs worked on it before I joined) to no avail since the login process stops once the app realizes that the user has already signed in...
So I guess that my question is this: Is there a way to link multiple Facebook accounts at once in a single iOS app? If so, how exactly? Forget the IAPs if that's too confusing, everything is fine there anyways. The goal is to be as seamless as possible, so ideally there would be no need for the user to log out and log back into the other account (Something I've seen a lot in other Questions/Answers).
I don't think I am authorized to show the code to you guys (that would also require sharing the entire project, it's a real spider-web!), but could someone please lead me in the right direction?
Please let me know if you have any questions!
Thank you in advance.
Notes:
Just like the title says, we use Firebase for our storage, Cloud Firestore for our database and Facebook login (through Firebase) for login since the purpose of the app is to schedule posts on IG.
I use a basic variable called "activeUsers" to track the number of accounts "linked" to the app so we can know whether or not to show the "PurchaseModel" and, obviously, receipt verification and all that for IAPs. Thought it could be useful!
3. When the app starts, you are prompted to link a Facebook account to enable the scheduler. THIS WORKS GREAT! What I am trying to achieve is to add other accounts AFTER the first one has been "enabled"/logged into.
It's not possible to link multiple accounts from the same provider to a single Firebase Auth account.
You can only link multiple accounts of different types (Facebook, Google, GitHub, etc) to a single Firebase account as described in the documentation.
Related
So we've developed a Facebook App (and similar apps on Twitter and Instagram) that allow users to post and read content using an external system. We'll sell this integration directly to our clients, so it's a private application.
Basically the user will see a very simple page with a button "Log in to Facebook" and a disclaimer regarding the authorization (we'll use some query params fixed in the url, depending on the client). The client authorize us and we capture the access tokens.
To submit the app review, though, we have to explicitly give a test user to the reviewers, but that's not really possible because the real "action" happens within the integrated systems, NOT within the app itself. And those systems are not public (they shouldn't be).
So just to be clear: our app is basically a very simple "Facebook login" that we use to get tokens, generated by specific clients authorization. It's not going to be published anywhere.
Until we have around 5 to 10 clients we can add the specific users in our app as Testers/Admins/etc, but what if we scale up? Say we have 20 clients. How are we supposed to get our app to be "live"?
To follow the app review steps we would have to create some users in our local systems (we have some dev environments), open them to the internet so the reviewers can log in and see how it actually works? Is that it?
(btw I'm asking this because our app review was rejected twice and I want to make sure I'm submitting everything they ask this time).
Thanks :)
I think the Login Review FAQ answers most of your questions. The key point:
Our review team will actually test how your app uses each permission on every platform you have listed in the settings section of your app.... You'll need to explain exactly how to test each permission or feature in your app so that we can make sure it works and follows our policies. We can't approve your app if we can't fully test how it integrates with Facebook.
In other words, it's not enough to just allow them to log in to your app, you have to expose all Facebook-related features to the reviewer.
To follow the app review steps we would have to create some users in our local systems (we have some dev environments), open them to the internet so the reviewers can log in and see how it actually works? Is that it?
Yes, though I'm not sure what you mean by "open them to the internet". You should be able to create a test user on your local system and link that account to a test Facebook user. Then you can have the Facebook reviewer use that test account for their review. (From the FAQ: "In the Items in Review section, you'll see a Test User (optional) section that allows you to type the name of the user you wish to be used in your review.")
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.
I am working on PHP application which will be shipped to many users for their own.
App needs to integrate
Facebook api for auto post their web articles to their fb profile/page.
Twitter api for same purpose as above and to search for tweets/users.
Youtube api to upload videos to their user account.
I already have completed the software, Right now software has api settings menu for each of them. Where user create their own app on respective platform and setup app id/secrets etc... IT works fine...
But I am looking for a way where, we use our own app codes, and user only has to click on button which redirect them to their platform and they can allow access to our app. So they dont have to go through their own app creation.
Just like how login with social media things work...
I know thats possible and my question is not about how to do this...
My question is about IF I do that, will that create any App usage limitation issues for users ? For example, if I create my own Youtube app settings from http://console.developers.google.com/ and all users just authorise my app to their account, will it create any issues if all users (may be 2000 users) uploads upto 5 videos per day ? Will the usage limit counted per application or per user access assigned ?
I need the answer for facebook/twitter and youtube. I know some one how has already done this can answer this quickly and easily...
Thanks for reading my question...
I have developed an iOS app that allows users to login via their Google Account using OAuth.
It was rejected by Apple for allegedly violating 11.13 of the App Store Review Guidelines:
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy" button that goes to a web site to purchase a digital book, will be rejected
Upon asking for more information, Apple said:
To clarify, your app has been rejected for including means for users to acquire new Google accounts. Linking customers to a page where users may sign up or register new accounts, and then use those accounts to purchase service/server space to be used within the app, is not appropriate and must be removed before resubmitting your app.
Here's a screenshot of the infringing functionality:
The Gmail iOS app has the same screen and I can't find any other app that connects to Google by OAuth so I'm at a loss on how to fix this.
Any ideas?
Many thanks!
EDIT: Here's a screenshot of same offending screen in Gmail
Edit
Google has finally added a native library that performs in-app sign in. You can find it here https://developers.google.com/identity/sign-in/ios/start
Original Post
This has happened to several users and unfortunately Google are still "working" on a solution.
I would strongly recommend that anyone facing this issue please comment in the official forum. The more attention it gets the higher the chance something will be done about it. Here's what one of the employees at Google had to say:
Hi all -- at Google, we aim to make our services available to as many
users and developers as possible. We have heard a very small number of
reports of problems of this type, but those app developers appear to
have eventually gotten approval to launch by working through Apple’s
standard process.
Meantime, we're continuing to work on improved mechanisms for login. I
do agree with Daniel that direct use of GTMOauth2ViewControllerTouch,
or the equivalent UIWebView trickery, is not recommended.
Right now the solution I used was to remove Sign In from the Launch Screen and move it to the menu inside our app.
Place a link mentioned below instead of SignUP button:
https://accounts.google.com/SignUp?service=mail&continue=https%3A%2F%2Fmail.google.com%2Fmail%2Fca%2F<mpl=default&hl=en
This link should be open in iOS Safari browser.
I had the exact same thing happen to me, but for a different service (SmugMug). In my situation, I worked with SmugMug and they provided for me an OAuth authorization page that didn't have the sign up button.
Some months ago, same thing with Dropbox. Dropbox also ended up providing a login page without a sign up button temporarily, but they got a little more cooperation with Apple.
Perhaps we can try to collectively get Google to provide the same. Even though we're iOS developers, Im' sure Google wants to support development of iOS apps that use their platform.
Have you tried contacting Google?
I know about test accounts, but during beta I'd like to allow access only to my friends, and then later friends-of-friends, and then only eventually Kevin Bacon and his friends.
That would probably suck, wouldn't it? The app would be listed (is there a way to prevent listing?) and someone I don't know might try it and get a "sorry, this is in development message." I imagine they'd be irritated and not come back.
From what I've read, only a few apps take off, but when they take off, they REALLY take off. Do developers just release these things fully baked?
Anyone start out with OpenSocial or other smaller-than-Facebook networks?
Any ideas for a soft, gradual, restricted roll-out?
Once you've set up your application, there is a setting in the Developer application control panel for your app: Your app -> Advanced -> Sandbox Mode.
Sandbox mode lets you restrict access to only those people listed as developers (under the Basic section).
In terms of expanding the app, Facebook doesn't provide much more flexibility that the Sandbox mode. Unfortunately, adding everyone as Developers of the app doesn't work very well for a beta, as people can access the application control panel once they are a developer. I ended up putting a whitelist of Facebook Ids into the front controller of my application for a previous beta, and it worked fairly well.
The apps are only listed in the App Directory if you submit them and they are accepted. There's no issue about preventing listing, it's something you have to apply for.
As for restricting users, you can accomplish it with a script in the application that checks whether the currently logged-in user is within your restricted user set. For example, if you only want friends of yourself, check whether the current user is friends with your user id. If not, simply display an error/message page or redirect them to the Facebook home page (or wherever). Add this check to the rest of the start-up logic run each page (such as connecting to your DB and authenticating with Facebook).
What I have done in some cases is keep a database table with the user id's of users who are allowed access, essentially a "whitelist". If the user isn't in the table, redirect them.