Suplantación de cuentas de Trade-In: investigar desde el lado del cliente
Cómo la suplantación se acota al portal de clientes de Trade-In, por qué arranca desde el detalle de la cuenta, y qué evita acotar el perfil y las notificaciones a la empresa suplantada.
El módulo Trade-In tiene su propia capa de autenticación, su propio RLS y su propio modelo de usuario, separados de la aplicación del operador por buenas razones. Lo que significa que suplantar a un cliente de Trade-In necesita su propia vía: la herramienta de suplantación del lado operador no llega a la superficie del cliente. El detalle de la cuenta de Trade-In en /admin/customers/[id] es donde vive esa vía.
Qué hace
Desde el detalle de la cuenta, un usuario del personal de plataforma inicia una sesión suplantada para esa empresa cliente. El botón pide primero un motivo de soporte de al menos cinco caracteres y después abre el portal del cliente tal y como lo vería esa cuenta: sus solicitudes de recogida, sus pujas, sus ITAD adjudicados, sus facturas, sus notificaciones. Solo lectura: se aplica el mismo bloqueo de escritura que en la suplantación del lado operador, y el aviso del portal lo dice exactamente así: “Solo lectura · Sesión de 30 minutos · registrado por auditoría”.
Por qué una página aparte
Porque los clientes de Trade-In y los usuarios operadores viven en tablas distintas, con caminos de unión distintos hacia las empresas. El flujo del lado operador asume relaciones de operador con inquilino; el lado Trade-In asume relaciones de cuenta con cliente. Cablear los dos en una sola herramienta habría sido un enredo de condicionales: una entrada separada para cada uno es más limpia, y el detalle de la cuenta es donde ocurre el soporte de cuentas de Trade-In de todos modos: datos de la empresa, umbrales de aprobación, miembros, solicitudes de recogida recientes y las recogidas que cuelgan de ellas.
Perfil y notificaciones acotados
El componente de perfil y el de notificaciones leen la empresa suplantada de forma explícita cuando hay un contexto de suplantación activo. Eso mantiene al usuario del personal en la superficie del cliente: el perfil del cliente, las notificaciones del cliente, sin decoración de la cuenta del personal. La página de perfil del propio portal sigue la regla de ver primero y editar después de la aplicación —un cliente edita nombre, apellidos y teléfono y cambia su contraseña ahí, mientras el correo y el rol del portal son de solo lectura para todos— y bajo suplantación la página entera es de solo lectura, así que un agente de soporte nunca puede sobrescribir por accidente el perfil de un cliente. Un visor del portal no ve el botón “Nueva solicitud” y recibe una explicación dentro del portal si abre directamente la página de creación, y quien suplanta ve el mismo portal que ve el cliente, explicaciones incluidas.
Cuenta atrás en el banner
La suplantación muestra un banner en la parte superior con el nombre de la empresa, el aviso de solo lectura y el tiempo restante. La cuenta atrás se deriva de la caducidad del lado servidor, así que se mantiene estable entre cargas de página y el tiempo que queda de sesión nunca es una conjetura.
Registro de auditoría
Iniciar la sesión escribe un evento de actividad con el usuario del personal, la cuenta del cliente y el motivo; terminarla escribe otro. Las sesiones caducan solas a los 30 minutos, e iniciar una nueva revoca la anterior. Cuando un cliente pregunta si alguien de la plataforma miró su cuenta, la plataforma responde con filas: quién, qué cuenta, cuándo empezó, cuándo terminó y por qué.