Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Buforowanie poświadczeń w połączeniach NTLM KA
Interfejs API serwera HTTP buforuje poświadczenia wyłącznie na połączeniach Keep-Alive (KA) podczas uwierzytelniania NTLM. Domyślnie interfejs API serwera HTTP buforuje poświadczenia uzyskane na pierwszym żądaniu wysłanym w połączeniu KA. Klient może wysyłać kolejne żądania dotyczące połączeń KA bez nagłówka autoryzacji i otrzymywać uwierzytelnienie na podstawie wcześniej ustalonego kontekstu. W takim przypadku interfejs API serwera HTTP wysyła token na podstawie buforowanego poświadczenia do aplikacji. Poświadczenia dla żądania wysłanego przez serwer proxy nie są buforowane. Aplikacja wyłącza buforowanie poświadczeń NTLM, ustawiając flagę DisableNTLMCredentialCaching w strukturze HTTP_SERVER_AUTHENTICATION_INFO, która jest dostarczana w wywołaniach do httpSetServerSessionProperty lub HttpSetUrlGroupProperty. Gdy buforowanie poświadczeń jest wyłączone, interfejs API serwera HTTP odrzuca buforowane poświadczenia i wykonuje uwierzytelnianie dla każdego żądania
Buforowanie poświadczeń NTLM dla określonych adresów URL
Aplikacja określa, czy poświadczenia żądania zwrócone przez interfejs API serwera HTTP są buforowane przez sprawdzenie parametru Flags struktury HTTP_REQUEST_AUTH_INFO. Ten parametr wskazuje na HTTP_REQUEST_AUTH_FLAG_TOKEN_FOR_CACHED_CRED, gdy zwrócony token NTLM został pobrany z pamięci podręcznej. Ustanowienie buforowania poświadczeń jest przewidziane dla grupy adresów URL obejmującej wszystkie adresy URL w tej grupie. Buforowanie poświadczeń na podstawie adresu URL nie jest obsługiwane, jednak aplikacje mogą określić, czy zaakceptować lub odrzucić buforowane poświadczenia na podstawie adresu URL, sprawdzając flagę HTTP_REQUEST_AUTH_FLAG_TOKEN_FOR_CACHED_CRED w strukturze HTTP_REQUEST_AUTH_INFO. Aplikacja odrzuca buforowane poświadczenia, wysyłając do klienta wyzwanie uwierzytelniania 401. Następnie klient ponownie wysyła żądanie z nagłówkami autoryzacji, inicjując nowy proces uwierzytelniania z użyciem API serwera HTTP.
Uwierzytelnianie podstawowe
Gdy w żądaniu znajduje się nagłówek uwierzytelniania podstawowego, interfejs API serwera HTTP analizuje nagłówek w celu uzyskania nazwy użytkownika i hasła. Nazwa użytkownika jest następnie analizowana w części użytkownika i domeny. Interfejs API serwera HTTP buforuje token dostępu uzyskany do uwierzytelniania podstawowego na podstawie nazwy użytkownika i klucza domeny. Po odebraniu nowego żądania interfejs API serwera HTTP pobiera token dostępu na podstawie nazwy użytkownika i domeny. Hasło w żądaniu jest następnie sprawdzane względem buforowanego hasła. Buforowany token dostępu jest usuwany po osiągnięciu limitu czasu wygaśnięcia (TTL).