Niestandardowe zakładki Chrome na Androida/interfejs WWW Fitbit nie będą przekierowywać, jeśli aplikacja jest już autoryzowana. (OAuth2.0)

Question

Zamierzam stworzyć aplikację fitbitową innej firmy do synchronizacji alarmów.

Jednak napotkałem pewne trudności związane z rejestracją mojej aplikacji, bardziej wyraźnie na uzyskanie tokenu dostępu, nawet jeśli mój klient jest już zarejestrowany w aplikacji. (Biorąc pod uwagę scenariusz ponownego zainstalowania aplikacji przez użytkownika).

używam niestandardowych zakładek Chrome (jak WebView jest zabronione przez Fitbit) do żądania tokenu dostępu:

String url = "https://www.fitbit.com/oauth2/authorize?" + 
        "response_type=token" + 
        "&client_id=XXXXXX" + 
        "&scope=activity"+ 
        "&redirect_uri=fitbittester://logincallback"; 
      customTabsIntent.launchUrl(MainActivity.this, Uri.parse(url)); 

Po przekierowanie do systemu niestandardowego zdefiniowanym z intent-filter:

działanie testowe powinny uruchomić, gdzie Wezmę AccessToken z danego zamiar:

public class TestActivity extends AppCompatActivity { 

String string; 

@Override 
protected void onNewIntent(Intent intent) { 
    string = intent.getDataString(); 
} 

@Override 
protected void onCreate(Bundle savedInstanceState) { 
    super.onCreate(savedInstanceState); 
    setContentView(R.layout.activity_test); 
    Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar); 
    setSupportActionBar(toolbar); 
    onNewIntent(getIntent()); 
    Toast.makeText(TestActivity.this, string , Toast.LENGTH_LONG).show(); 
    Log.e("TAG", string); 
    Log.e("TAG", string.substring(string.indexOf("&access_token")+14)); 
} 

}

Wszystko działa poprawnie przy pierwszym uruchomieniu (pod warunkiem, że klient nie jest jeszcze autoryzowany), ale po tym, jeśli chcesz odzyskać mój token dostępu (wiem, że powinienem przechowywać go lokalnie - najprawdopodobniej SharedPreferences, ale tylko w celach testowych), niestandardowe zakładki chrome zostaną otwarte i pozostaną na pustej stronie (widocznie nie będzie to poprawnie przekierowywać).

Przeczytałem FitBit WEB API i napisano: Jeśli aplikacja używająca przepływu Implicit Grant wysyła użytkownika do strony autoryzacji przed wygaśnięciem wydanego wcześniej tokenu dostępu, użytkownik nie zostanie poproszony, chyba że zakres zwiększył się. Użytkownik zostanie natychmiast przekierowany do aplikacji za pomocą tokena dostępu.

Moje pytanie brzmi, czy w moim sposobie myślenia o problemie jest błąd, czy też w przypadku błędu niestandardowych zakładek Chrome powinienem przechwycić?

Dziękuję bardzo z góry.

Answer 1

Znalazłem obejście tego problemu. Zasadniczo wstawiam nowy parametr do adresu URL z zapytaniem o interfejs API Fitbit. ("& prompt = login"). Ten parametr spowoduje, że użytkownik będzie ponownie logował się za każdym razem, gdy zapyta o token autoryzacji, wylogowując go, jeśli jest już zalogowany.

Answer 2

Domyślam się, że fitbit wykonuje przekierowanie 302, gdy użytkownik jest już zalogowany. użył tego rozwiązania (pomieszał to rozwiązanie z CustomTabActivityHelper z Chrome tab demo) i naprawił problem. Yay.

udało mi się „naprawić” ten problem poprzez wywołanie funkcji nagrzewania przed ładuje adres URL, który przekierowuje.

Chrome Custom Tabs redirect to Android app will close the app