Chrome onAuthRequired: sprawdź isProxy przed wysłaniem danych logowania
Wywołanie zwrotne uwierzytelniania Chrome może opisywać wyzwanie serwera proxy lub wyzwanie źródła. Podanie tym dwóm tym samych danych logowania to błąd zakresu danych.
Rozszerzenie przeglądarki może napotkać wyzwania uwierzytelniania z dwóch różnych miejsc: serwera proxy przenoszącego żądanie i docelowej witryny. Nie powinny one automatycznie otrzymywać tego samego konta.
Użytecznym rozróżnieniem w zdarzeniu webRequest.onAuthRequired Chrome jest isProxy. Wywołanie zwrotne, które usuwa to sprawdzenie tylko po to, by zniknął monit, może zacząć podawać dane logowania proxy wyzwaniu źródła.
Dopasuj serwer proxy, któremu zamierzasz zaufać
Sprawdzanie isProxy to początek. Ogranicz też obsługę do oczekiwanego wyzywającego proxy i kontekstu żądania. Rozszerzenie zarządzające wieloma punktami końcowymi powinno wybierać konto należące do tego punktu końcowego, a nie jedno globalne hasło do każdego wyzwania.
Nie zakładaj, że ustawienie trasy proxy i obsługa jej logowania to jedno uprawnienie lub jedno wywołanie API. Chrome dokumentuje je osobno. Użyj aktualnego odwołania webRequest do danych zdarzeń i uprawnień uwierzytelniania. Przykład rejestracji nasłuchującego Manifest V3 pokazuje synchroniczną rejestrację i wybór konta wewnątrz wywołania zwrotnego.
Sprawdź generację manifestu
Przykłady wspominające eksperymentalne API WebRequest pochodzą ze starych wydań rozszerzenia. Obecne wymagania dotyczące uprawnień zależą od generacji manifestu rozszerzenia i modelu wdrożenia. W szczególności obsługa uwierzytelniania ma własną obsługiwaną ścieżkę uprawnień; przestarzały przykład blokującego nasłuchującego nie wystarcza, by wykazać, że rozszerzenie Manifest V3 może go uruchomić bez zmian.
Poprawny moduł obsługi musi też unikać niekończącego się ponawiania tych samych odrzuconych danych logowania. Drugie wyzwanie po podaniu konta traktuj jako dowód do zbadania, a nie jako prośbę o wieczne odtwarzanie hasła.
Dane logowania powinny pozostawać na odpowiedniej chronionej ścieżce obsługi rozszerzenia. Nie publikuj ich w pliku PAC ani nie wpisuj na stałe w dystrybuowanym przykładzie. Celem jest wąsko ograniczone logowanie proxy, a nie reguła dla całej przeglądarki odpowiadająca na każde wyzwanie uwierzytelniania tym samym sekretem.