Jednokrotne logowanie (Singe Sign-On) nie działa, gdy aplikacja Facebook jest zainstalowana na urządzeniu

Question

Pracuję nad aplikacją na Androida, która integruje się z Facebookiem. Aplikacja działa doskonale, gdy ustawię LoginButton.setLoginBehavior (SessionLoginBehavior.SUPPRESS_SSO).

Problem pojawia się, gdy próbuję użyć SSO. Otrzymuję błąd poniżej. Kiedyś użyłem nieprawidłowego klucza, gdy użyłem nieprawidłowego klucza; tak już nie jest, ponieważ log z Webview działa dobrze. Zaskakujące jest to, że aplikacja na Androida działa, jeśli aplikacja jest zainstalowana w FB. Na przykład, jestem menadżerem aplikacji, dlatego domyślnie jest instalowany w moim profilu na Facebooku, ale kiedy próbuję z innym kontem fb, które nie ma zainstalowanej aplikacji, to nie działa. Kiedy próbuję się zalogować, pojawia się poniższy błąd i pojawia się okno dialogowe z informacją, że podstawowe uprawnienia zostaną przyznane, ale w rzeczywistości nie otrzymuję nawet podstawowych uprawnień.

Przesłałem aplikację do sprawdzenia, aby była widoczna w App Center. Kiedy to zrobię, okno dialogowe pokazuje pole wyboru, w którym potwierdzam, że moja aplikacja używa SSO. Czy Facebook musi zatwierdzić moją aplikację, zanim będę mógł korzystać z SSO (jeśli tak, to nie ma sensu)

Spędziłem wiele godzin próbując rozwiązać ten problem i nie mogę znaleźć rozwiązania. Proszę pomóż.

08-24 01:39:16.058: W/Bundle(21880): Key com.facebook.platform.protocol.PROTOCOL_VERSION expected String but value was a java.lang.Integer. The default value <null> was returned. 
08-24 01:39:16.068: W/Bundle(21880): Attempt to cast generated internal exception: 
08-24 01:39:16.068: W/Bundle(21880): java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String 
08-24 01:39:16.068: W/Bundle(21880): at android.os.Bundle.getString(Bundle.java:1069) 
08-24 01:39:16.068: W/Bundle(21880): at android.content.Intent.getStringExtra(Intent.java:4350) 
08-24 01:39:16.068: W/Bundle(21880): at com.facebook.AuthorizationClient$KatanaLoginDialogAuthHandler.tryAuthorize(AuthorizationClient.java:821) 
08-24 01:39:16.068: W/Bundle(21880): at com.facebook.AuthorizationClient.tryCurrentHandler(AuthorizationClient.java:272) 
08-24 01:39:16.068: W/Bundle(21880): at com.facebook.AuthorizationClient.tryNextHandler(AuthorizationClient.java:238) 
08-24 01:39:16.068: W/Bundle(21880): at com.facebook.AuthorizationClient$GetTokenAuthHandler.getTokenCompleted(AuthorizationClient.java:772) 
08-24 01:39:16.068: W/Bundle(21880): at com.facebook.AuthorizationClient$GetTokenAuthHandler$1.completed(AuthorizationClient.java:731) 
08-24 01:39:16.068: W/Bundle(21880): at com.facebook.internal.PlatformServiceClient.callback(PlatformServiceClient.java:144) 
08-24 01:39:16.068: W/Bundle(21880): at com.facebook.internal.PlatformServiceClient.handleMessage(PlatformServiceClient.java:128) 
08-24 01:39:16.068: W/Bundle(21880): at com.facebook.internal.PlatformServiceClient$1.handleMessage(PlatformServiceClient.java:54) 
08-24 01:39:16.068: W/Bundle(21880): at android.os.Handler.dispatchMessage(Handler.java:99) 
08-24 01:39:16.068: W/Bundle(21880): at android.os.Looper.loop(Looper.java:137) 
08-24 01:39:16.068: W/Bundle(21880): at android.app.ActivityThread.main(ActivityThread.java:5227) 
08-24 01:39:16.068: W/Bundle(21880): at java.lang.reflect.Method.invokeNative(Native Method) 
08-24 01:39:16.068: W/Bundle(21880): at java.lang.reflect.Method.invoke(Method.java:511) 
08-24 01:39:16.068: W/Bundle(21880): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:795) 
08-24 01:39:16.068: W/Bundle(21880): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:562) 
08-24 01:39:16.068: W/Bundle(21880): at dalvik.system.NativeStart.main(Native Method) 

Answer 1

Miałem podobne wyjście logcat i okazało się, że było to związane z błędnością w kodzie źródłowym FB 3.5. Jak opisano powyżej, jest on na linii 821 w AuthorizationClient.java. Powinien być getIntExtra zamiast getStringExtra. Pobierz źródło z github i zmienić

intent.getStringExtra(NativeProtocol.EXTRA_PROTOCOL_VERSION)); 

do

""+intent.getIntExtra(NativeProtocol.EXTRA_PROTOCOL_VERSION, 0)); 

Answer 2

Problem jest hashkey jest Wong

Dla Linuksa

Otwórz Terminal:

Do debugowania

keytool -exportcert -alias androiddebugkey -keystore debug.keystore | openssl sha1 -binary | openssl base64 

wil znaleźć debug.keystore z „.android” folderu skopiuj i wklej go z na pulpicie i uruchomić powyższe polecenie

za zwolnienie produkcji

keytool -exportcert -alias <aliasName> -keystore <keystoreFilePath> | openssl sha1 -binary | openssl base64 

UWAGA: Upewnij się, że w obu przypadkach należy zwrócić się do hasło. Jeśli nie prosi o podanie hasła, oznacza to, że coś jest nie tak w poleceniu.

Answer 3

Nie jestem pewien, czy jest to pomocne, ale może być związane z nowym wydaniem SDK. Czy korzystasz z Androida SDK w wersji 3.5? Może spróbuj użyć starszej wersji SDK, 3.0.2, możesz go znaleźć przeglądając ich github repository.

Edit:

Naprawiłem problem w moim przypadku, ale nie mogę powiedzieć, że wiem, co rzeczywisty problem jest:

• Sprawdź hash i APP_ID upewnij się, dodaj swój hash do swojej aplikacji na stronie programisty, zamiast przykładowej aplikacji.

• Upewnij się, że tę aktywność Manifest zawiera dokładnie jak określono/pojawia się w próbkach

  aktywność android: name = "com.facebook.LoginActivity” android: theme = "@ android: styl/Theme.Translucent.NoTitleBar"
  android: label = "@ ciąg/nazwa_aplikacji"

• Upewnij się dodać meta-danych w < application> tag swojego manifestu

  meta-danych android: name = "com.facebook.sdk.ApplicationId" android: value = "@ ciąg/app_id"

• Upewnij się, że na swoich twórców konto Facebook, aplikacji, którą W przypadku ponownego wdrożenia określono poprawny pakiet i nazwę głównej klasy

• Ja również usunąć następujące atrybuty z moim głównym aktywności logowania w manifeście:

  android: eksportowanego = "true" android: Nohistory = "true"

To, co zrobiłem, i wydaje się działać na razie, nie mogę powiedzieć, czy jest to uniwersalna poprawka, ale przynajmniej warto sprawdzić, czy wszystkie te są poprawne.

Answer 4

Fakt, że logowanie przez WebView działa, nie oznacza, że ​​hashkey jest poprawny, ponieważ działa nawet wtedy, gdy w ustawieniach aplikacji na Facebooku nie ma skrótu. Więc sprawdź jeszcze raz swój haszysz.

Poza tym, że mówisz, że działa tylko z Twoim profilem, a nie z innymi, sprawdź, czy prawidłowo dodano je jako testerów lub że nie jesteś w trybie piaskownicy.

Answer 5

OK, o to, co się działo. Na moim onCreate() przekazywałem uprawnienia "create_event" i "publish_actions" do mojego LoginButton. I poszedł do przodu i ustawić onErrorListener na LoginButton i byłem coraz to:

08-28 14:06:01.679: E/FACEBOOK LOGIN ERROR(28293): UnknownError: The app must ask for a basic_info permission at install time. 

Jak się okazuje, po zainstalowaniu, aplikacja HAS do żądania odczytu uprawnienia pierwszy, a raz jesteś zalogowany mogłeś zapytaj o uprawnienia do publikowania. Here jest jak facebook wyjaśnia (pod Publishing Uprawnienia):

Aplikacje należy oddzielić prośbę odczytu i publikują uprawnienia. Zaplanuj swoją aplikację, aby uzyskać wymagane minimum uprawnień do odczytu przy pierwszym logowaniu, a następnie wszelkie uprawnienia do publikowania, gdy osoba faktycznie ich potrzebuje, na przykład, gdy chcą utworzyć historię otwartego Wykres z poziomu aplikacji. Zapewnia to najlepsze doświadczenie użytkownika i optymalizuje konwersję.

Możesz otrzymywać alerty programisty, jeśli aplikacja prosi o pozwolenie na odczytywanie i publikowanie uprawnień. Aby przestać otrzymywać te alerty, oddzielaj swoje prośby lub postępuj zgodnie z poniższymi wytycznymi dla wyjątkowych przypadków .

W rzadkim przypadku, gdy aplikacja wymaga uprawnień wydawniczych góry przód (na przykład aplikacja, która nic nie robi, ale publikuje nastrój użytkownika do Facebook), pierwszy wniosek gołe minimalne uprawnienia czytać w początkowym logowania. Gdy użytkownik zaloguje się na Facebooku, pokaż użytkownikowi ekran wyjaśniający, dlaczego Twoja aplikacja wymaga uprawnień do publikowania, i pozwól użytkownikowi na zaakceptowanie prośby o pozwolenie na publikację przez kliknięcie przycisku. To zapewni użytkownikowi więcej kontekstu i poprawi konwersję.

Kolejnym uzasadnionym przypadkiem prośby o uprawnienia do odczytu i publikowania w wersji back-to-back są użytkownicy, którzy logują się do Twojej aplikacji za pomocą adresu e-mail lub opcji logowania innej niż Facebook. Gdy użytkownicy ci chcą opublikować na Facebook'u numer , Twoja aplikacja będzie musiała poprosić o uprawnienia do odczytu, aby połączyć się z ich kontem, a następnie publikować uprawnienia do siebie. W tej sprawie upewnij się, że jedyne uprawnienia do odczytu, o które prosisz, to publiczny profil i lista znajomych z . Zapewnia to najlepsze wrażenia użytkownika, ponieważ użytkownik chce po prostu opublikować go w swojej aplikacji i nie jest zainteresowany udostępnieniem dodatkowych uprawnień do odczytu. Poprawi to również konwersję.

Aby rozwiązać mój problem, ja po prostu nie żądać żadnych uprawnień rozruchu (dostaniesz „basic_info” czytać uprawnienia domyślne), a następnie użyłem

helper = new UiLifecycleHelper(this, new StatusCallback() { 

      @Override 
      public void call(Session session, SessionState state, Exception exception) { 
       // TODO Auto-generated method stub 
       if(state.isOpened()&&!session.getPermissions().contains("publish_actions")) 
        session.requestNewPublishPermissions(new NewPermissionsRequest(SplashScreen.this, "publish_actions")); 

      } 
     }); 

w onCreate (). Ponieważ wywołanie() zostaje wywołane za każdym razem, gdy nastąpi zmiana w sesji, funkcja session.isOpen() będzie prawdą, jeśli nie sprawdzimy, czy uprawnienie jest ustawione, wprowadzimy nieskończoną pętlę.

Podobno powyższe ostrzeżenie nie miało nic wspólnego z rzeczywistym błędem. Tak jak sugerują ludzie, którzy mają takie problemy, ustaw on onRebrorListener i zapisz go.

Log.e("FACEBOOK LOGIN ERROR", error.getLocalizedMessage());