I'm writing an app for a retailer, but my client wants that once that the user has logged in the app does not let him/her log out.
My question is: Is this a permitted behavior on Apple apps? Will it get rejected? I've been looking up for a policy related to this, but haven't found anythin that either allows or denies this.
Thanks in advance.
You cannot prevent the user from just killing the app. But she does not necessarily be logged out. If you mark her as "logged in" by means of some persistant store (such as user preferences), you can have him be logged in automatically next time she starts the app.
This is a design that I have seen in many apps. I do not think that it would get you rejected. The user would have to delete the app completely to log out.
One possibility: put a "change login" option into the preferences. At least on iPhone, that is very far away from the app, at the bottom of the settings app which most users never find. Even then you could only let the user be logged out completely once she is logged in with a different valid login.
My recommendation: don't take the control away from the user. Explain to your client that there is a balance between marketing necessities and the danger of annoying important customers who might unduly amplify negative sentiments. Accomodate the needs of your client by making it a bit tedious to log out - but not more.
Related
After a Facebook user authorizes the app, the user has to be verified manually by a live person which needs to see details of his profile, including his pictures etc.
What would be the correct way to implement this?
Should the app download all necessary data from the user's profile after the user authorizes the app? Seems a lot of wasted effort if there is an easier way.
I have already posted this question to http://webapps.stackexchange.com here.
You can't see a whole lot of details on ones profile without that user having authorized your app. You can however see the ProfilPicture, so if that is most important it would be possible.
And since (I presume) a user starts on your own page/site you could add a check in there so that someone can click an 'accept-button' on your side...
But what I really wonder is, why not just make sure the people you don't want to be authorized with you app don't know where to reach the app??
Think that's way easier to sort out a bunch of people...
I have a similar query to Can someone please put an end to "LEAVE APP" misery! with a differing behaviour.
Our application asks for permissions, the user gets an allow / disallow option, however if the user clicks to try to authorise again (within a short space of time) they will instead see a dialog with allow / leave app.
This is disrupting our application flow slightly as the leave application will take users directly to their facebook profile and not back to our site (as we explain the benefits of allowing our application).
Has anyone experienced this and / or knows a way to prevent this from occurring?
I'm almost sure this is deliberate, and designed to provide a way for users to quickly exit authentication loops
This is an intentional design choice in the permissions dialog. It can't be overridden.
The issue I am having is that in the authentication box are login/cancel buttons. This is not what I want, I am wanting it to show Allow/Don't Allow.
I thought this was the default but for some reason it is showing up differently.
I am not sure why this would be happening. Any help on this problem would be much appreciated.
You can view the app at https://apps.facebook.com/found-it-on-carsale/
Basically, user need to login(in other words,authorize the application)...After that,user will need to allow/dont allow the application...Once the user allow the application,it will not showing allow/dont allow again...The most important thing is,user must login....
Thats a part of protocol.Once user authorize him self or herself for a particular application next time when user will come he/she will be asked to login and since they have already approved access, they will not be asked again.
user will be asked to approve/deny if
User changed his/her password.
Your application has been disabled for some reason
You have changed the scope
Why you want user to approve/deny your access request every time when he has already approved and has shown faith on your application? it will create bad user experience
Whenever I first click on a Facebook app it puts up a screen asking for permissions. Does the API enforce this, or is it possible to display a screen using either fake or the user's publicly accessible data?
You do not have to ask for any permissions right away. Your app can have the equivalent of a "guest" mode, similar to how many websites work until the user has logged in. I'm not sure why more apps don't operate like that, as a user I'm always a bit put off when something asks for permission before I've even seen the first page of it.
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.