I am not sure if anyone has ran into the problem but it is really bugging me and affecting our uploading from our iPad to facebook.
I have a local server running XAMMP with a gallery of images displayed via a local web page. These images are from our Photobooths and automatically get added into the gallery when a photo is taken in the booth.
These can then be accessed on the local network via the iPad. Users can then login to facebook and share this images.
Because this is a shared iPad being used by multiple users, is there any way of getting users to login without having to answer security questions?? It used to be fine but now Facebook says the login is suspicious as it does to recognise the device.
I have created an App to post the photos to facebook through the Facebook Development site and it works perfectly from my account and many users, but some seem to get the suspicious login attempt and have to identify friends and date of birth etc.
Is there a correct way to do this?
Thank you Richard.
Is there a correct way to do this?
What you are experiencing is the “correct” way.
Facebook offers this as a security feature – a user can add his devices to his list of “known” devices, from which he will be able to login straight away, and have to answer additional security questions when logging in from a different, “unknown” device.
If users have this feature enabled, they should not be surprised by this happening in your scneario. It’s what they explicitly want, and they’re getting it.
So you should in no way try to mess with that, just because you might think this to be “uncool” or a “nuisance” – it’s not, it’s a feature offering extended security that the user wants and has explicitly chosen.
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'm developing an app that authenticates users with Facebook. I'd like to display the user's profile picture in their account, which is readily accessible via a public Facebook URL.
Am I permitted to directly link to these images for use in our app, or do we need to download the image and re-host it on our own servers? I wasn't able to find any answer in the terms of service.
You should NOT use the CDN link, because that one may not be valid forever. It is perfectly fine to download the profile image - if you REALLY want to be safe, tell the user about it before he authorizes your App. You need to have a privacy policy anyway, stating what exactly you store about the user.
It is perfectly fine to use the Graph API link though. Depending on how many images you want to show, it may be better to still download them for performance reasons.
I'm building an app that uses OpenID for authentication. I'm giving Google, Yahoo and the general OpenID site as options.
At present, when the user selects a site, I open a UIWebView and the user performs their login with that frame, all within the app.
However, it has struck me that when using UIWebView, you cannot easily show to the user that the connection is over https or that they are indeed at the site I'm claiming they are at. I could be easily harvesting passwords.
Would it be, and I'm looking for opinions on this, be better from a user confidence perspective to actually open Safari when the user selects a login and once they've logged in have Safari direct me back to app?
Thanks
Most people using iOS devices are used to the way Facebook logins work; no URL bar, no nothing. I'd just follow the typical workflow. You could bump out to Safari, and return via a custom URL scheme. However, I think users will think that is more weird. iOS users are not used to being jumped in and out of different apps.
just my 2 cents, it would be also faster if the user has already logged in those services with Safari before.
Prompting out a UIWebView and switching to Safari is using the same amount of steps, so why not?
I thought I'd follow up on this thread to say I'm having difficulties getting the app approved and I think it's because I use the Safari approach. I've had it rejected by Apple twice now because:
"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 "
I think it's because I'm launching Safari. I've opened a dispute with Apple and I'll come back with more information once I hear back from them. I really hope a quick change to a UIWebView will help!
I've been trying to get this to work for a while, but I've apparently missed something.
All I want is to have the latest 3 or so posts from my clients Facebook page to populate and animate in a screensaver that I am building using Flash (AS3).
So far, every time I try to bring anything in, it requires a complete oAuth login and account link, but it's only a one way exchange (read-only, absolutely no writing, posting or even linking, since it's a screensaver) I'm not even sure the client wants pictures or anything.
I am currently trying to use the facebook-actionscript-api, but there isn't an option for the "App Login" type of Authentication that would solve most of my problems.
I'm at wits end and about to have to tell my client it can't be done. At least they'll always have twitter...
I don't think it is possible to get facebook feeds without an accesstoken (even if they are public). So I guess you need to define an app within Facebook and add login stuff to your app so users can give permission to your app for basic access.
Maybe this article offers some help: http://www.adobe.com/devnet/facebook/articles/flex_fbgraph_pt1.html
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.