Abra a páxina de cambio de contrasinal e léaa como o faría un usuario, e despois pregunte que servizo posúe realmente a credencial. A páxina é un formulario; o almacén de identidade é a autoridade. Se os dous non coinciden, o usuario atopa un contrasinal rexeitado, un restablecemento que non restablece nada ou unha mensaxe de éxito que non cambia nada. Percorrer o fluxo da pantalla ao backend é a única forma de detectalo.

Comece clasificando a operación: un cambio normal, un fluxo de contrasinal caducado ou unha recuperación tras un contrasinal esquecido.

Tres operacións, tres fluxos de traballo

Un cambio normal supón que o usuario coñece o contrasinal actual e pode demostralo. Un fluxo de contrasinal caducado pode permitir unha sesión limitada na que só se permite o cambio. A recuperación tras un contrasinal esquecido necesita unha proba de identidade completamente distinta, e pode delegarse nun provedor de identidade en lugar de xestionarse na pasarela VPN. Cada unha ten o seu propio punto final, soporte de backend e regras de sesión, e un só formulario non pode atender correctamente as tres.

Nunha implantación federada, a pasarela pode non recoller ningún contrasinal novo. Comprobe se o fluxo redirixe ao provedor de identidade e se o texto da páxina segue describindo un formulario local.

De onde vén realmente a política

Pregunte ao propietario da identidade a lonxitude permitida, o conxunto de caracteres e calquera restrición aplicable, e despois escriba instrucións que coincidan. Inventar regras de composición no texto de axuda, ou prometer unha aceptación que o backend rexeita, ambos xeran tickets de soporte. As directrices NIST de identidade dixital inclínanse por unha orientación clara e comentarios útiles en lugar de regras arbitrarias, mentres que a política real da organización segue mandando. Unha publicación non é proba de que un directorio concreto xa se comporte así.

Manteña as mensaxes de erro útiles sen filtrar segredos. Unha mensaxe que repite un contrasinal escrito parcialmente, ou unha captura de pantalla nun ticket que conteña un, converten un artefacto de soporte nunha exposición de credenciais.

Redacción que coincide co backend

A páxina debería nomear o fluxo de traballo en lugar de describir a política en abstracto. Diga onde ocorre o cambio, que proba se require e que pasa coas outras sesións. Se o cambio pecha a sesión do usuario en todas partes, dígao; se deixa outros dispositivos activos, dígao tamén. Un usuario confuso que reintenta un cambio correcto é un custo de soporte que unha mellor redacción evita.

A localización pode cambiar o ton das instrucións; non pode cambiar o que acepta o backend.

Probe o fluxo, non a páxina

Utilice unha conta de proba permitida e percorra o cambio documentado, un caso de rexeitamento, o caso de contrasinal caducado e o inicio de sesión posterior. Onde o MFA ou unha redirección federada formen parte do fluxo aprobado, percorrao tamén. Unha páxina que se representa correctamente verificou a presentación e nada máis, porque o servizo de identidade decide se a operación de credencial se completou.

Rexitre o resultado de cada caso coa conta utilizada e a hora. Un fluxo que funciona unha vez para un administrador e falla para un usuario normal é un resultado habitual, e o rexistro é o que o fai visible.

Despois actualice a páxina para describir que ocorreu realmente. Esa é toda a tarefa.

Artigos relacionados