Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firebase Auth - Facebook signin violates facebook app requirements #1465

Closed
ryanzor opened this issue Sep 28, 2018 · 7 comments
Closed

Firebase Auth - Facebook signin violates facebook app requirements #1465

ryanzor opened this issue Sep 28, 2018 · 7 comments

Comments

@ryanzor
Copy link

ryanzor commented Sep 28, 2018

Environment

  • Android device: _____Pixel
  • Android OS version: _____P
  • Firebase/Play Services SDK version: _____16.0.3 (firebase core)
  • FirebaseUI version: ____4.2.0

The problem:

Facebook is getting very stringent on their app review process. I recently had an app rejected from submission because my login button does not match Facebook guidelines (https://developers.facebook.com/docs/facebook-login/best-practices#brandedlogin). Specifically with FirebaseUI if Facebook is the only login option firebaseUI goes ahead and starts the facebook login flow, this seems to not be okay with Facebook app approvers and will be a cause for an app not being approved for Facebook login.

Steps to reproduce:

  1. _____Make Facebook the only login option
  2. _____Iniate login flow
  3. _____Notice you don't see the "Login with Facebook" button that matches Facebook branding guidelines

Relevant Code:

In sign in kickstarter the below method should have an "or facebook is the provider" in the if statement. Alternatively, it may make sense to add a flag to force showing the auth method choice. This would not change the behavior for existing clients and allow users to make their own "Login with Facebook" button if they wanted. The main downside would be that Facebook review process is now 1-2 weeks with little feedback so I'd expect more people trying out FirebaseUI to lose those weeks without realizing they need to set the flag.

 private void startAuthMethodChoice() {
      // If there is only one provider selected, launch the flow directly
      if (getArguments().isSingleProviderFlow()) {
@samtstern
Copy link
Contributor

@ryanzor thanks for filing this! This is an interesting and important development.

The relevant policy (from this page) seems to be:

Use a clearly branded log in button that follows the guidelines in the Facebook Brand Resource Center.

@samtstern samtstern added this to the 4.2.1 milestone Oct 2, 2018
@samtstern
Copy link
Contributor

@ryanzor what UI does your app show before launching into FirebaseUI? It seems like another solution would be for you to put a "Log in with Facebook" button into your own app and then launch the single-provider FirebaseUI flow from there.

@SUPERCILEX
Copy link
Collaborator

SUPERCILEX commented Oct 2, 2018

On our side, it shouldn't be too hard to force the picker activity to show just Facebook. But yeah, if you have a login button that only shows 1 IDP, then might as well be branded.

@samtstern
Copy link
Contributor

@ryanzor in version 4.2.1 we have added the following option:

setAlwaysShowSignInMethodScreen(boolean)

So once that version is released, you'll be able to easily comply with Facebook's requirements. Of course I think it's a better suggestion not to do that and instead to add a Facebook branded button to your app's own UI since our screen doesn't look too pretty with just one button.

@ryanzor
Copy link
Author

ryanzor commented Oct 4, 2018

Thanks @samtstern & @SUPERCILEX ! I agree, adding a button on my side would work, and this is what I did to deal with facebook app approval process. The current flow of my login though is that most the app is accessible without logging in, but there are a few buttons that essentially say "Do Action" and bring the user to the login flow if needed, they look out of place with the Facebook branding so I likely will move to use the flag.

I'm fine closing this issue, but I'm not sure what your standard approach is for that

@samtstern
Copy link
Contributor

@ryanzor we leave the issue as "Fix Implemented" until the release actually goes out, then we close it. Thanks for asking!

@samtstern
Copy link
Contributor

This has been fixed and released in version 4.2.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants