VPN slaptažodžio keitimo puslapis: suderinimas su tapatybės saugykla
Forma nėra valdžia. Išsiaiškinkite, kuri saugykla valdo slaptažodį, parašykite jos politiką atitinkančias instrukcijas ir išbandykite keitimo, atmetimo bei atstatymo kelius.
Atidarykite slaptažodžio keitimo puslapį ir perskaitykite jį taip, kaip skaitytų naudotojas, tada paklauskite, kuri paslauga iš tikrųjų valdo prisijungimo duomenis. Puslapis yra forma; tapatybės saugykla yra valdžia. Jei abi nesutampa, naudotojas susiduria su atmestu slaptažodžiu, atstatymu, kuris nieko neatstato, arba sėkmės pranešimu, kuris nieko nekeičia. Eigos nuo ekrano iki backend perėjimas yra vienintelis būdas tai pagauti.
Pradėkite nuo operacijos klasifikavimo: įprastas keitimas, pasibaigusio galiojimo slaptažodžio eiga arba atkūrimas pamiršus slaptažodį.
Trys operacijos, trys darbo eigos
Įprastas keitimas daro prielaidą, kad naudotojas žino dabartinį slaptažodį ir gali tai įrodyti. Pasibaigusio galiojimo slaptažodžio eiga gali leisti ribotą sesiją, kurioje leidžiamas tik keitimas. Atkūrimas pamiršus slaptažodį reikalauja visiškai kito tapatybės įrodymo, ir jis gali būti perduotas tapatybės teikėjui, o ne tvarkomas VPN šliuze. Kiekviena turi savo galinį tašką, backend palaikymą ir sesijos taisykles, ir viena forma negali tinkamai aptarnauti visų trijų.
Federacinėje diegimo aplinkoje šliuzas gali visai nerinkti naujo slaptažodžio. Patikrinkite, ar eiga nukreipia į tapatybės teikėją ir ar puslapio tekstas vis dar aprašo vietinę formą.
Iš kur politika iš tikrųjų ateina
Paklauskite tapatybės savininko apie leistiną ilgį, ženklų rinkinį ir visas taikomas apribojimus, tada parašykite juos atitinkančias instrukcijas. Sudėties taisyklių išgalvojimas pagalbos tekste arba pažadas priimti tai, ką backend atmeta, abu sukuria palaikymo bilietus. NIST skaitmeninės tapatybės gairės linksta prie aiškaus nurodymo ir naudingo grįžtamojo ryšio, o ne savavališkų taisyklių, o tikroji organizacijos politika vis tiek galioja. Publikacija nėra įrodymas, kad konkretus katalogas jau elgiasi būtent taip.
Išlaikykite klaidų pranešimus naudingus neatskleisdami paslapčių. Pranešimas, atkartojantis iš dalies įvestą slaptažodį, arba biliete esanti ekrano nuotrauka, kurioje jis yra, palaikymo artefaktą paverčia prisijungimo duomenų atskleidimu.
Formuluotė, atitinkanti backend
Puslapis turėtų įvardyti darbo eigą, o ne abstrakčiai aprašyti politiką. Pasakykite, kur vyksta keitimas, koks įrodymas reikalingas ir kas nutinka kitoms sesijoms. Jei keitimas atjungia naudotoją visur, pasakykite tai; jei kiti įrenginiai lieka aktyvūs, pasakykite ir tai. Sumišęs naudotojas, kartojantis sėkmingą keitimą, yra palaikymo išlaidos, kurių geresnė formuluotė išvengia.
Lokalizacija gali pakeisti instrukcijų toną; ji negali pakeisti to, ką priima backend.
Testuokite eigą, o ne puslapį
Naudokite leistiną bandomąją paskyrą ir pereikite dokumentuotą keitimą, atmetimo atvejį, pasibaigusio galiojimo slaptažodžio atvejį ir vėlesnį prisijungimą. Kai MFA arba federacinis nukreipimas yra patvirtintos eigos dalis, pereikite ir tai. Teisingai atvaizduojamas puslapis patikrino pateikimą ir nieko daugiau, nes tapatybės tarnyba sprendžia, ar prisijungimo duomenų operacija baigta.
Užrašykite kiekvieno atvejo rezultatą su naudota paskyra ir laiku. Eiga, kuri vieną kartą veikia administratoriui ir nepavyksta įprastam naudotojui, yra dažnas rezultatas, ir būtent įrašas tai padaro matoma.
Tada atnaujinkite puslapį, kad aprašytų, kas iš tikrųjų įvyko. Tai ir yra visa užduotis.