Firefox працягвае выкарыстоўваць стары ўліковы запіс проксі
Стары лагін проксі можа паходзіць з актыўнага сеансу аўтэнтыфікацыі, захаванага пароля або інтэграванага ўваходу. Ачыстка кукаў вэб-сайта ўздзейнічае на іншы ўзровень.
Спачатку ўдакладніце, якое імя хоста проксі і які ўліковы запіс паведамляе адміністратар або журнал проксі. Старое імя карыстальніка, якое паказвае вэб-сайт, можа быць яго ўласным сеансам на аснове кукаў, а не уліковым запісам, які выкарыстоўваецца на пасярэдніку.
| Магчымая крыніца | Наступная праверка |
|---|---|
| Актыўны сеанс аўтэнтыфікацыі HTTP | Калі ўсталяваны выпуск прапануе ачыстку актыўнага ўваходу, выкарыстоўвайце гэтую вобласць, а не толькі кэшаваныя выявы. Закрыйце ўсе працэсы Firefox перад паўторным адкрыццём, каб выключыць неадназначнасць асобнікаў. |
| Захаваныя ўліковыя даныя проксі | Знайдзіце адпаведны захаваны лагін і выдаліце толькі непатрэбны запіс. |
| Інтэграваная аўтэнтыфікацыя | Праверце, ці ідэнтычнасць АС і кіраваная палітыка аўтэнтыфікацыі адразу зноў прадастаўляюць уліковы запіс. |
Асобны кэш аўтэнтыфікацыі HTTP у Firefox апісаны ў запісе пра праблему Mozilla. Даступнасць інтэрфейсу ачысткі залежыць ад усталяванай версіі. Ачыстка кукаў вэб-сайта ўздзейнічае на іншы ўзровень.
Кіраваная палітыка можа наўмысна дазваляць SPNEGO або NTLM праз проксі. Гэта адрозніваецца ад адраса канчатковай кропкі і звычайных пароляў вэб-сайтаў. Змяніце механізм, які падае непажаданую ідэнтычнасць, замест таго каб прымяняць доўгі спіс непаўязаных перамыкачоў about:config.
Для задачы, якая патрабуе іншай ідэнтычнасці, выкарыстоўвайце схему, якую падтрымлівае адміністратар проксі. Пастаяннае выдаленне кукаў кожнага вэб-сайта не можа даказаць прыналежнасць гэтага ўліковага запісу.