Jak zapobiec przechwytywaniu przez Safari 401 odpowiedzi na żądania ajax

Question

Mam następujący problem w rozszerzeniu Safari. Poprosiłem użytkownika o podanie nazwy użytkownika/hasła do usługi internetowej i wysłanie szybkiej prośby o sprawdzenie, czy dane logowania są poprawne. Jeśli tak nie jest, usługa odpowie 401, jak sądzę, powinna. Problem polega na tym, że Safari wydaje się przechwytywać tę odpowiedź, zanim mój kod javascript poradzi sobie z tym, pokazując szare pole logowania, zamiast pozwolić mi poradzić sobie z błędem.

Czy mogę coś z tym zrobić? Używam biblioteki js do wywołania, ale funkcjonalnie odpowiada to jQuery.

$.ajax({ 
    type: "GET", 
    url: url, 
    username: username, 
    password: password, 
    success: function() { /* handle success */ }, 
    error: function() { /* handle error */ } 
}); 

Answer 1

O ile jestem świadomy (po miałem ten problem ja) nie sposób dostaniesz Safari powstrzymać przechwycenie 401. Jeśli te ustalenia są poprawne, jedynym sposobem jest kreatywność (czytaj: niewłaściwe) użycie innego kodu błędu, np. 403 lub używając niestandardowego (patrz poniżej).

Oczywiście zakłada to, że użytkownik ma dostęp do zmiany kodu statusu odesłanego z usługi internetowej (nie jest całkowicie jasne, czy w związku z pytaniem o rozwój usługi internetowej).

, oczywiście, mówi "jesteś już uwierzytelniony, ale nie masz uprawnień dostępu do tego zasobu", co nie jest poprawne (stąd "niewłaściwe użycie"), ale przynajmniej nie ma żadnych skutków ubocznych w przeglądarkach, które Jestem swiadomy.

jest czasem używana jako alternatywa, ale ponieważ ta ("zła prośba") ma oznaczać błąd protokołu HTTP, może wywoływać efekty uboczne (nigdy jej nie można zobaczyć lub usłyszeć, ale potencjalnie, może spowodować, że niektóre przyszłe przeglądarki lub programy anty-włamujące spowodują zbyt pomocną próbę rozpoczęcia rozwiązywania problemów/diagnostyki).

412 to kolejna alternatywa, że ​​widziałem używany („warunek nie powiodło się”), ale faktycznie ma wskazywać, że serwernie spełniał warunków koniecznych do żądania zestawu.

Możesz też utworzyć niestandardowy błąd o numerze 4xx - np. 461 - co jest dozwolone (zauważ, że Twitter ma zwyczaj 420 kod stanu, na przykład)

Answer 2

Bardziej właściwe podejście byłoby nadal korzystać 401 jako kod błędu, ale nie wysyła nagłówek WWW-Authenticate gdy poświadczenia zostały wysłane ale nie były prawidłowe.

To nie powoduje już uruchomienia okna przeglądarki i umożliwia bezpośrednie przetwarzanie 401.