I am software tester working on outsourced projects for many clients.
Frequently, I am required to test Facebook apps just before they go live. Often, the content of the app requires several interactions with other Facebook friends, including pulling of tagged photos and retrieving a user's info.
Most advice suggests that I should be using Facebook test accounts, created by a developer of a specific app. However, due to the complexity of some of the requirements in order to fully test certain apps, a dummy account - pre-filled with 'real' information is much more practical to use. It is clear that if we were to add all of this detail to Facebook test accounts for every new project, we would never get any time to actually test the app.
My company has approximately 20-30 dummy user accounts on Facebook, all of which have a good level of detail including personal info, photos, friend networks etc. These are perfect for testing as they are normal Facebook accounts. We always set option to private to prevent any sensitive material from being seen by the general public.
Over the last moth or more, our dummy user accounts are being systematically wiped out where Facebook is blocking them. Clearly, we cannot re-instate these accounts as we have no ID for the 'dummy' users.
Our aim is to aid the developers to improve the quality of their Facebook apps, and so has no detrimental effect on Facebook as a company or a brand.
Is there any way to achieve our requirements without the constant battle to maintain our dummy accounts?
Login to facebook. Then use /whitehat in the URL. On the left hand side you will get an option to create test accounts.
Test users are the only way to do this without violating Facebook's terms of service.
You can use multiple apps with a Test User, assuming you're not deleting and recreating them between test runs
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.
I have a multi-tenant web application and I'm wondering which would be the best way to let all the tenant publish their content on the feed of their facebook page (if they have one of course).
There's no public page/link to share so all the shared content has to go straight to the feed (using JS with FB.api feed + photos...). I am wondering which is the most proper way to accomplish this task: having one FB app for every tenant, or using the same FB app for all the different pages, or some other way...
Any suggestions?
I would set this up using a Facebook app for each tenant. This would be forward thinking if you ever want to do further Facebook integration. This also protects your tenants from eachother's behavior. If one tenant violates Facebook policy (There's a lot more of it nowadays) and gets their app locked or anything similar then it won't affect your other tenants ability to interact with Facebook. Also if your application is a white label app then giving each tenant their own Facebook app is almost necessary. Of course each clients having their own app does incur maintenance costs. Whenever Facebook decides to deprecate functionality or implement new features that require their Migration strategies, you'll have to manage each of the apps individually at developers.facebook.com, and depending on how many tenants you have and which features you've integrated with, that can be become tedious since there's no way of automating confirmation of compliance for all of the apps set up. Also now there's a review process for a lot of integration features. That review process would be required for each of the apps individually depending on the features implemented.
I am working on an automated test script to create test users and connect them as friends with each other to load test and profile parts of my app.
The test user documentation states a limit of a maximum 500 test users per application.
https://developers.facebook.com/docs/test_users/
An app can create up to 500 test users to start testing an app. If you exceed the limit of test users you can create for an app you will receive an error.
Anyone else out there ever needed to push past this limit, and how did you achieve testing with communities of users larger than 500? I want to test with users who have between 2000 and 3000 Facebook friends. Yes, such characters are out there in the real world :) Note: as per a comment below it is highly unusual to find users with such large numbers of friend connections. See the comment for a link to stats.
One option which I'm experimenting with is to create multiple apps and "friend" the test users between apps, which seems to be possible. This seems like unnecessary work though.
I'm also considering stubbing the Facebook API with my own local server, but this feels wrong too. There might be libraries for doing this easily?
Since no one has answered this for quite a while, I thought I'd just post the way I solved this for now, in case someone else needs it some day.
Facebook allows you to add and "share" test users between multiple apps for which you are an administrator.
Therefore, I created several extra test Facebook apps for myself, besides the one I am already testing.
Then I added almost 500 test users to each (using the create test user API call).
I then associated some existing "core" test users across all the apps from the original test application (see below for documentation on how to do this) taking the additional apps up to their 500 limit.
Once the "core" users were added across all the test apps, I then made the "core" users friends with all the other users in each test app (this needs to be done within each test app - ie using the access tokens of the additional test app, not the original app).
The final result is that the "core" group from the original app are friends with users from outside the original app, allowing their friend list to grow beyond the artificial testing user limit of 500. So from the original app I now have a collection of core users who can have as many friends as I'm prepared to go to the hassle of creating, in batches just under 500 in size.
There might be an easier way, but that's it for now.
I didn't explore the idea of stubbing the Facebook API - still an interesting idea!
From the documentation:
Adding existing test users to other apps
You can add existing test users to other apps by using the Graph API with the app access token that you're adding the user to.
https://graph.facebook.com/APP_ID/accounts/test-users?
installed=true
&permissions=read_stream
&uid=TEST_USER_ID
&owner_access_token=APP_ACCESS_TOKEN_OWNER
&access_token=APP_ACCESS_TOKEN
&method=post
Parameters:
uid : User id of the existing test user
owner_access_token : App access token of the app used to create the test user
Facebook Test Users Documentation: http://developers.facebook.com/docs/test_users/
I'm working on developing a Facebook application that accesses the user's friends list.
Since some can have thousands of friends, what's the best method to simulate this?
I want to performance test before letting it out in the wild.
Does Facebook have any sandbox account where one can create dummy accounts?
Facebook have recently implemented a feature allowing you to add up to 50 test users, it's probably not enough users to reliably test though:
http://developers.facebook.com/docs/test_users/
Why not ask a couple of users with lots of friends to beta test for you?
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.