Closed RigoFlores closed 11 years ago
jccastillo0007
commented
11 years ago En el menu de administracion, ellos podran dar de alta sus usuarios y sus preferencias.
Nosotros daremos de alta los usuarios en la base de datos, con un usuario inicial
Las cuentas si deben ser case sensitive.
RigoFlores
commented
11 years ago ENTONCES ESTA PREGUNTA SE CONVIERTE EN FALLA, YA QUE HOY EN DÍA LAS CUENTAS SON CASE INSENSITIVE. ENTIENDO QUE EN EL MENÚ DEL KEYGENERATOR, DEBERÍA CAPTURARSE EL USUARIO? EL USUARIO Y PWD INICIAL PODRÍAN SER LA PRIMERA SECCIÓN DEL CORREO (ANTES DEL @), Y ELLOS DEBERÍAN TENER LA POSIBILIDAD DE CAMBIAR EL PWD CADA OCASIÓN QUE REQUIERAN. Y NOSOTROS TENER LA POSIBILIDAD DE RESETEARLO (PARA CUANDO SE LES OLVIDE EL PWD).
jccastillo0007
commented
11 years ago Fixed.
Ya es case sensitive y en el key generator se pide usuario y password del administrador principal.
Posteriormente en el menu Admin, se podran dar de alta mas usuarios, asi como resetear el pwd.
RigoFlores
commented
11 years ago Al momento de dar de alta la llave, se debería generar el usuario y pwd del ADMINISTRADOR de nuestro cliente. Solamente el ADMINISTRADOR de nuestro cliente, puede dar de alta otros usuarios, que serán del perfil de usuario. El perfil usuario, podrá dar de alta catálogos, generar factura y consultar. Las demás opciones no aplican para usuario.
Ahora mismo, cualquier usuario, puede dar de alta usuarios.
jccastillo0007
commented
11 years ago Correcto.
RigoFlores
commented
11 years ago ??
jccastillo0007
commented
11 years ago fixed....
Ahorita ya no da acceso a las opciones especiales para un administrador o para nosotros, aun tengo que trabajar un poco mas para que no muestres dichas opciones.
Pero este no es un bloquer porque para la version de produccion se pueden eliminar dichas opciones facilmente,
RigoFlores
commented
11 years ago Estaba revisando, y creo que se debería implementar lo siguiente: a) al dar de alta una nueva llave, deberá crear por omisión, usuario y pwd del emisor, siendo ambos el rfc emisor en mayúsculas. Este usuario tendrá perfil de administrador b) Al entrar por primera vez deberá pedirle que cambie su pwd c) Un admin tendrá acceso al menú admin: usuarios, configuración y reporte de facturación d) Un admin podrá dar de alta usuarios, a quienes no les aparecerá la opción de admin, solamente el resto de las opciones. El usuario y pwd del usuario, serán los mismos cuando se dan de alta. e) Un usuario, al momento de acceder por primera vez, tendrá que cambiar su pwd. La validación para pedir esto, es usuario=pwd. f) Los usuarios no podrán repetirse en todo el universo de usuarios, y eso lo notificará el sistema al momento de tratar de agregar un nuevo usuario. g) Solicitar un cambio periódico del pwd tanto para usuarios y admins. h) El menú admin de la TIA, definitivamente es diferente que el resto de los admins. Incluso, creo que debería ser otra URL.
El punto f creo que podría llegar a complicarse, pero de entrada tendría que ser así, mientras no se encuentre un mecanismo para distinguir un usuario rijo de rfc A, del mismo usuario rijo para un rfc B. Que opinas?
jccastillo0007
commented
11 years ago Fixed..
b y e) El tema de forzar el cambio de password, no lo veo necesario
f) no es necesario, ya se tiene identificado de que RFC es cada usuario
g) no lo veo necesario en este momento.
h) ya esta generado un ambiente exclusivo para esto.
JC
RigoFlores
commented
11 years ago b y e repetidos por cierto) El tema de forzar el cambio de pwd, es protección para nosotros. Nos exime de conocer (en teoría) el pwd admin de nuestros clientes, ya que nosotros 'podríamos generar facturas con dolo'. Aún contando con cláusula de confidencialidad y declaración de privacidad, ante una auditoría, nosotros también contaríamos con esa co-responsabilidad en la generación de facturas. g) La mayoría de los bancos lo aplica; es una mejor práctica en temas de seguridad. f) De acuerdo, siempre que no exista conflicto del usuario rijo, repetido en varios RFC's por ejemplo. h) De acuerdo a) De acuerdo
RigoFlores
commented
11 years ago Lo cerraré porque ya se dan de alta automáticamente los clientes en web. Abriré un pendiente para el cambio de pwd al inicio y periódico, para no perderlo de vista
PARA PROPÓSITOS DE INICIAR CON UN PILOTO, POSIBLEMENTE CON 2-3 CLIENTES, CÓMO ESTARÍAMOS ADMINISTRANDO SUS CUENTAS, Y ELLOS A SU VEZ, CÓMO ESTARÍAN ADMINISTRANDO SUS USUARIOS.?
HOY EN DÍA, EL MENÚ DE ADMINISTRACIÓN, SOLO NOS SIRVE A NOSOTROS, PERO A LOS CLIENTES NO.
POR CIERTO, LAS CUENTAS NO SON (Y NO SE SI DEBERÍAN O NO), CASE SENSITIVE.