I am using this app for instant articles. For three hours, I am getting the below error; what do I need to do? When I asked if instant articles apps also need to do app review, the FB support team told no need to review. But now I am getting this error:
Invalid Scopes: manage_pages, pages_manage_instant_articles,
publish_pages. This message is only shown to developers. Users of your
app will ignore these permissions if present. Please read the
documentation for valid permissions at:
https://developers.facebook.com/docs/facebook-login/permissions
Also I am using login product: I am not using the login to collect details from users. I only use this to login from my component, to give access from my site to instant articles.
This is the reason why you are getting that error:
Public Mode — Apps in public mode no longer allow their admins, developers, or testers to access permissions or features that normally
require app review. This affects all apps built after May 1st, 2018,
immediately. Apps built before then will not be affected until August
1st, 2018.
More information here: https://developers.facebook.com/docs/graph-api/changelog/version3.0, under the section titled "90-Day Breaking Changes".
Related
We're implementing Gmail sending in out ASP .NET web application with Gmail .NET SDK.
In order to do this we need all following scopes "email", "profile", "openid",
https://www.googleapis.com/auth/gmail.send" to be granted to us by user.
However, on the consent screen user can untick checkbox "Send email on your behalf" which is not acceptable for us, please see below:
We've seen quite a few examples where there are no enabled checkboxes on the Google consent screen. So, we're truiyng to figure out how to hide/disabled checkboxes in our app, could you please advise?
Probably, this is because of our application is still not verfified, but I'm not sure if this is the reason.
Answer:
These checkboxes are due to the rolling out of a new granular account permission system, they are completely normal, and can not be turned off.
More Information:
After some digging, I discovered this Google Developers blog post from 2018 in which it is discussed that in the new permission system, users will have the ability to grant or deny permissions individually.
From the blog post:
Over the next few months, we'll start rolling out an improvement to our API infrastructure. We will show each permission that an app requests one at a time, within its own dialog, instead of presenting all permissions in a single dialog*. Users will have the ability to grant or deny permissions individually.
*our different login scopes (profile, email, and openid are all combined in the same consent and don't need to be requested separately.
It seems that this is still in the roll-out phase, even though at the time of writing this answer 26 months have passed since the announcement.
Preparing for the change:
The following are guidelines provided by Google as to how to prepare for the changes they are making to the Google Account permission system for OAuth and APIs:
Review the Google API Services: User Data Policy and make sure you are following them.
Before making an API call, check to see if the user has already granted permission to your app. This will help you avoid insufficient permission errors which could lead to unexpected app errors and a bad user experience. Learn more about this by referring to documentation on your platform below:
Documentation for Android
Documentation for the web
Documentation for iOS
Request permissions only when you need them. You'll be able to stage when each permission is requested, and we recommend being thoughtful about doing this in context. You should avoid asking for multiple scopes at sign-in, when users may be using your app for the first time and are unfamiliar with the app's features. Bundling together a request for several scopes makes it hard for users to understand why your app needs the permission and may alarm and deter them from further use of your app.
Provide justification before asking for access. Clearly explain why you need access, what you'll do with a user's data, and how they will benefit from providing access. Our research indicates that these explanations increase user trust and engagement.
You can read the aforelinked blog post for full information about the change.
References:
Google Developers Blog: More granular Google Account permissions with Google OAuth and APIs
Google API Services User Data Policy | Google Developers
GoogleSignIn | Google APIs for Android | Google Developers
Google Sign-In JavaScript client reference
Requesting additional scopes after sign-in | Google Sign-In for iOS
We're implementing Gmail sending in out ASP .NET web application with Gmail .NET SDK.
In order to do this we need all following scopes "email", "profile", "openid",
https://www.googleapis.com/auth/gmail.send" to be granted to us by user.
However, on the consent screen user can untick checkbox "Send email on your behalf" which is not acceptable for us, please see below:
We've seen quite a few examples where there are no enabled checkboxes on the Google consent screen. So, we're truiyng to figure out how to hide/disabled checkboxes in our app, could you please advise?
Probably, this is because of our application is still not verfified, but I'm not sure if this is the reason.
Answer:
These checkboxes are due to the rolling out of a new granular account permission system, they are completely normal, and can not be turned off.
More Information:
After some digging, I discovered this Google Developers blog post from 2018 in which it is discussed that in the new permission system, users will have the ability to grant or deny permissions individually.
From the blog post:
Over the next few months, we'll start rolling out an improvement to our API infrastructure. We will show each permission that an app requests one at a time, within its own dialog, instead of presenting all permissions in a single dialog*. Users will have the ability to grant or deny permissions individually.
*our different login scopes (profile, email, and openid are all combined in the same consent and don't need to be requested separately.
It seems that this is still in the roll-out phase, even though at the time of writing this answer 26 months have passed since the announcement.
Preparing for the change:
The following are guidelines provided by Google as to how to prepare for the changes they are making to the Google Account permission system for OAuth and APIs:
Review the Google API Services: User Data Policy and make sure you are following them.
Before making an API call, check to see if the user has already granted permission to your app. This will help you avoid insufficient permission errors which could lead to unexpected app errors and a bad user experience. Learn more about this by referring to documentation on your platform below:
Documentation for Android
Documentation for the web
Documentation for iOS
Request permissions only when you need them. You'll be able to stage when each permission is requested, and we recommend being thoughtful about doing this in context. You should avoid asking for multiple scopes at sign-in, when users may be using your app for the first time and are unfamiliar with the app's features. Bundling together a request for several scopes makes it hard for users to understand why your app needs the permission and may alarm and deter them from further use of your app.
Provide justification before asking for access. Clearly explain why you need access, what you'll do with a user's data, and how they will benefit from providing access. Our research indicates that these explanations increase user trust and engagement.
You can read the aforelinked blog post for full information about the change.
References:
Google Developers Blog: More granular Google Account permissions with Google OAuth and APIs
Google API Services User Data Policy | Google Developers
GoogleSignIn | Google APIs for Android | Google Developers
Google Sign-In JavaScript client reference
Requesting additional scopes after sign-in | Google Sign-In for iOS
We have a mobile app and our users got a
"sign in with google temporarily disabled for this app"
When they tried to login their YouTube account with iOS (There's no problem with Android devices).
We submitted a verification request long time ago, and we got from YouTube an email (May 26th 2020),(May 26th 2020):
"Hi Adam,
Thanks for working with us on the YouTube API Services compliance review. We have completed your review and do not require any further actions from you at this time.
We may reach out again to re-review your API Client for compliance with YouTube API Services Terms and Policies.
We appreciate your time working with us on this and please continue to comply with the YouTube API Services Terms and Policies."
Since then, nothing had changed and our app hasn't been verified yet, and our users can't connect with their youtube accounts.
What can we do? We are just waiting and we don't even know how to contact YouTube and ask about our specific case/project.
Thanks you,
Adam.
sign in with google temporarily disabled for this app
Means that your application has not been verified by google. You need to go through the verification process.
You can use a project for development without verification. However there are some limitations (more information here). Basically, you have now reached the limit of 100 users accessing the application.
If you still havent heard anything from google after they say they have verified your application I think the only thing you can do is to submit it again and double check that you are using a client that was created under the project that you requested verification for there's really nothing else you can do.
I got following email from apple
1.0.1 Binary Rejected June 16, 2015
17.2 Details We noticed that your app uses Facebook login for authentication purposes but does not include account-based features
offered
I got following attachment
From Apple
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
17.2 Details
We noticed that your app uses Facebook login for authentication
purposes but does not include account-based features offered by that
site, which is not allowed on the App Store.
Next Steps
Please modify your app to include account-based features of that
social network or use your own authentication mechanism.
what is the reason behinds it.
I have study the following links
https://www.parse.com/questions/app-rejected-facebook-login-doesnt-complete
App got rejected because only using Facebook as login option?
Apple rejected app 10.6 because Facebook opens Safari to login
Apple review Guidelines says here
5.1.1 Data Collection and Storage
(ii) If your app doesn’t include significant account-based features,
let people use it without a log-in. Apps may not require users to
enter personal information to function, except when directly relevant
to the core functionality of the app or required by law. If your core
app functionality is not related to a specific social network (e.g.
Facebook, WeChat, Weibo, Twitter, etc.), you must provide access
without a login or via another mechanism. Pulling basic profile
information, sharing to the social network, or inviting friends to use
the app are not considered core app functionality.
I've a published app that has an optional login feature without any "account-based features".
I think providing a "continue as guest" option will fix the issue.
This means that your app didn't implement another feature of Facebook anywhere else in your application, if you're asking for explanation. If you make an app that just has Facebook's Log-in API, but nothing else, then your app will be rejected. Find another feature of Facebook (such as sharing or invites) that you can implement somewhere in your application, and try again.
A few possible steps you can take:
Ask App Store review people for clarification. Wait until you didn’t
get a response from them
You can make user registration optional or only prompt for it where
it actually requires
Try it.
Add note, while submitting app,the purpose of using Facebook login in resolution center without uploading new build it will be approve.
If still you face any issue then add some functionality of user login.
For Ex: Use of facebook login is for keeping all records of user in our database and also explain a bit about your app functionality why you use login feature.Hope it will help
Also check
iPhone app rejection 17.2: app requires users sign in with their Facebook accounts
Hello Everyone I am using the prime 31 facebook plugin for the Unity 3D engine and I am running into an issue of testing out the ability for our users to post a message containing their score onto their facebook wall.
I believe the issue is related to needing to add a publish_permission to my app yet I can't test this feature because I believe I have to have that permission approved to utilize it in my pap.
I also noticed that the approval process calls for explaining your usage of said permission and submitting your app with what I imagine would be a form of implementation .
So I guess my confusion has to do with the general process of having my publish permissions approved and whether or not i can make use of the publish permissions in my not-approved app for testing at the very least .
You should always be able to test your permissions with the admin/test/developer users of the specific app.
Have a look at https://developers.facebook.com/docs/apps/review/login#do-you-need-review which is stating that
...your app's developers will be able to see, and grant, any permission without requiring review by Facebook.
Note: People who are listed in your app's Roles tab will have access to extended permissions without going through review (e.g. publish_actions or manage_pages). For example, if you use the Facebook Plugin for Wordpress to publish your blog posts to your Facebook Page or Profile, you do not need to submit for review so long as all your publishers are listed in your app's Roles tab.
Also, if you're the developer of an app and are the only person using it, then your app doesn't need to go through review. Since you're the developer, all app capabilities should be available. You will still need to take your app out of developer mode, but you should be able to do that without going through review.