android - błąd salwy Nie znaleziono żadnych problemów z uwierzytelnianiem

Question

Próbuję pracować z jakimś starszym kodem i mam do czynienia z problemem podczas używania salwy.

Próbuję dostać się do api, że nasza główna strona ma i działa dobrze dla jednego konta, ale nie innego Próbuję dowiedzieć się, jakie mogą być różnice w adresie URL/nagłówku żądania, a także, co powraca w odpowiedzi, ale nie mogę znaleźć sposobu w kodzie volley, aby wydrukować to do dziennika.

Błąd Dostaję jest

com.android.volley.NoConnectionError: java.io.IOException: No authentication challenges found 

Czytałem wokół, że może to być spowodowane odpowiedzi 401, ale ja naprawdę nie wiem, co to znaczy albo przynajmniej jak udowodnić/przetestuj to. Jestem bardzo zdezorientowany, że działa na jednym koncie, a nie na innym.

Adres URL jest nieco inny, ponieważ adres URL jest dla naszej witryny w Wielkiej Brytanii, a drugi dla naszej strony AM, ale poza tym nie ma różnicy.

Dzięki

Answer 1

Ten błąd zdarza się, ponieważ serwer wysyła 401 (Nieautoryzowane), ale nie dać „uwierzytelniania w sieci WWW”, która jest wskazówką dla klienta, co robić dalej. Nagłówek "WWW-Authenticate" informuje klienta, jakiego rodzaju uwierzytelnienie jest potrzebne (Basic lub Digest). Zwykle nie jest to przydatne w przypadku bezgłowych klientów http, ale tak definiuje się standard. Błąd występuje, ponieważ lib próbuje przeanalizować nagłówek "WWW-Authenticate", ale nie może.

Możliwe rozwiązania, czy można zmienić serwer:

• Dodaj fałszywy „www uwierzytelnienie” nagłówek jak: WWW-Authenticate: Basic realm="fake". Jest to zwykłe obejście, a nie rozwiązanie, ale powinno działać, a klient HTTP jest zadowolony.
• Użyj kodu stanu HTTP 403 zamiast 401. To semantyczne nie jest takie samo i zwykle podczas pracy z loginem 401 jest poprawna odpowiedź (see here for a detailed discussion), ale jest wystarczająco blisko.

Możliwe rozwiązania, jeśli nie można zmienić serwer:

Jak @ErikZ napisał w swoim post można użyć spróbować & połowów przy

HttpURLConnection connection = ...; 
try { 
    // Will throw IOException if server responds with 401. 
    connection.getResponseCode(); 
} catch (IOException e) { 
    // Will return 401, because now connection has the correct internal state. 
    int responsecode = connection.getResponseCode(); 
} 

Zamieściłem to też tutaj: java.io.IOException : No authentication challenges found

Answer 2

Rzeczywiście, rozwiązałem ten problem, dodając nagłówek WWW-Authenticate do odpowiedzi serwera.

Jeśli jednak dodasz nagłówek WWW-Authenticate: Basic realm="", a Twój interfejs API zostanie również wykorzystany przez klientów sieciowych, niektóre przeglądarki internetowe będą wyświetlać wyskakujące okienko z pytaniem o podstawowe poświadczenia.

Dla mnie właściwe rozwiązanie korzysta z niestandardowego schematu. Jak wyjaśniono w tej publikacji: blog post, używam xBasic zamiast Basic w odpowiedzi nagłówka.

WWW-Authenticate: xBasic realm=""

Z tego nagłówka nie tylko Volley analizuje odpowiedzi poprawnie, ale również uniknąć przeglądarek internetowych pokazujące uwierzytelniania pop-up.

Answer 3

udało mi się złapać tego po stronie klienta podczas inicjalizacji RequestQueue volley:

Volley.newRequestQueue(getApplicationContext(), new HurlStack() { 
     @Override 
     public HttpResponse performRequest(Request<?> request, Map<String, String> additionalHeaders) { 
      try { 
       return super.performRequest(request, additionalHeaders); 
      } catch (AuthFailureError authFailureError) { 
       authFailureError.printStackTrace(); 
       // Log out/whatever you need to do here 
      } catch (IOException e) { 
       e.printStackTrace(); 
       if (e.getMessage().equals("No authentication challenges found")) { 
        // This is the error. You probably will want to handle any IOException, not just those with the same message. 
       } 
      } 
      return null; 
     } 
}); 

Answer 4

Jeśli serwer pada, może napotkać na ten problem. Kroki:

1. zatrzymać serwer Tomcat

2. goto Uruchom -> Usługi -> zrestartuj bazę danych (np postgres'owy)

3. uruchomić serwer Tomcat.

Answer 5

Możesz sprawdzić e jest instanceof AuthFailureError.

Log.e(TAG, "AuthFailureError: " + (e instanceof AuthFailureError));