Atentificación de usuarios en PHP

Estado
Cerrado para nuevas respuestas.
Salome

Salome

Lanero Regular
16 Dic 2002
18
Hola, sigo con el tema de las sessiones y las cookies..

Ahora, deseo hacer un sistema de autentificación, los datos como nombre de usuario y contraseña los tengo en mi base de datos y la contraseña se encuentra encriptada MD5.

Como deberia funcionar el sistema de autenficación, es decir:

1. verifico que el usuario exista.. esto lo hago por una session y si existe entonces que?.. guardo el dato en otra session o lo paso a una cookie??.. que forma seria la ideal y porque??..

2. mi usuario tambien puede tener niveles de acceso, estos niveles los guardo en una tabla en la base de datos.. o debería crear un archivo plano para tenerlo ahi?..

Bueno las dudas por ahora son un poco de conceptos.

Un saludo,:muerto:
 
1. Al verificar que el usuario existe, debes comparar el password que el ingresa con el password encriptado en la base de datos... Algo como: if (md5($formpassword) == $userinfo['password']) { //el usuario es válido }

De ahi seguirías a actualizar la información de sesión, y si quieres persistencia después de cerrar el browser, la información de cookies. Las cookies sólo son necesarias si necesitas que la información de sesión esté disponible incluso después de haber cerrado el browser.

2. Lo de los niveles de acceso es mejor manejarlo en el momento en que éstos se requieran.

Si se supone que ya autentificaste a un usuario, cuando éste intente entrar a una página restringida, como el control panel, hacer algo como:

$if ($permisos['controlpanel'] == true) {
// puede entrar
} else {
//no puede entrar
}

Es de verdad muy sencillo, pero funciona... El array $permisos lo tendrías que generar cada vez que ejecutes las rutinas de identificación.

Si necesitas más info, sólo coloca un mensaje :)
 
Se me olvidaba... LA información de permisos junto con otra información importante, siempre es bueno que esté en la base de datos... En archivos planos podrían ocurrir errores o cosas raras.....

Simplemente crea una tabla que contenga todos los permisos, y para cada permiso, un campo booleano en donde puedas escribir falso o verdadero (1 o 0).

Entonces eso lo podrías asociar directamente con un usuario, o si lo quieres más fácil, con un grupo de usuarios.
 
okas.. he leído algo sobre sessiones y esto de manejar las cookies suele ser algo no muy seguro para el manejo de usuarios.. que sabes de ello??.. que tan conveniente es que guarde información como esta en una cookie.. o mejor como debería guardarla??..

Y bueno si no estoy muy preguntona, te pregunto que versión de php me recomendas y que versión de mysql... se que la última version maneja ya las relaciones y transacciones y otras cosas como un buen motor de base de datos.. pero igual necesito al menos la recomendación de alguien que ya los haya utilizado.

Un saludo.
 
Guardar la información de autentificación en una cookie la hacen muchos sitios.... Al usuario se le dan todas las advertencias de que su información de identificación será guardada en el PC que está usando. Lo bueno sería que dieras dos opciones: Guardar en cookies y no guardar... Sería lo ideal.

Lo de la versión de php y mysql siempre es mejor utilizar las últimas versiones estables....
 
Pues es mejor tener las dos opciones, pues puede pasar que el usuario no tenga habilitadas las cookies y ahi tremendo lio..

okas.. grazie...:D
 
exacto , jejej asi es que se usa las mayorias de las veces .
Es mejor prevenir que curar jejeje
 
Con respecto a mysql, lo que dice Julian es cierto es mejor estar usando las ultimas versiones estables, ah! y un consejo por experiencia personal te recomiendo que uses tablas InoDB, aunque la ultima version de mysql estable creo que usa este tipo de tablas por default , tablas myisam sox, he tenido muchos problemas con ellas puede que sea mas rapidas las consultas con este tipo de tablas, pero de algo si estoy seguro y es que se c a g a n muy facil ademas de que no son transaccionales.
 
Pues bueno, ya hice mi autentificador, uso una tabla donde guardo el nombre de usuario, la contraseña y un nivel de acceso.

en un script tengo un arreglo con los mensajes de error, dependiendo del error que tenga sale el mensaje.. (obvio..jaja), error al conectarse a la base de datos, no existe, verificar nombre de usuario, contraseña.. cosas como esta.. permiso denegado tambien lo tengo.. 8(

al usuario conectarse, pasa por un control de usuarios que verifica si existe y todo es pasado por sessiones, la verdad no quice utilizar cookies pues de igual forma siempre pido sea logueado para ingresar.

Cada vez que se entra a una zona registringida, se llama la session, y comparo el nivel de acceso...

Bueno uno de mis tantos lios resuelto... gracias por sus respuestas...:bandido:
 
Pues a ver....entrando a los reconditos mundos de mysql de esto me entere...

"Mysql 4.0.x no soporta relaciones (claves foráneas, por lo menos en tablas MyISAM comunes..) .. eso está previsto para Mysql 4.1 (que todavía está en fase Alpha si no me equivoco).

Si has programado aplicaciones que usan Mysql con SQL de las versiones 3.23.36 .. no tendrás ningun problema para migrar hacia versiones 4.0.x de Mysql .. De hecho así lo hice yo y a lo "bruto" moviendo mi directorio "data" (donde Mysql guarda las BD y sus estructuras) "a pelo" sobre mi recien instalado Mysql 4.0.x .. sin problemas.

Los problemas de incompatibilidades .. (a no ser que cambien mucho) suelen ser a la inversa ... es decir .. si tu usas alguna sentencia o metodo de Mysql 4.0.x en una aplicación tuya y luego lo ejecutas en Mysql 3.x.x ahí es donde puedes tener problemas.

Sobre PHP y sus versiones .. lo mismo. En principio no deberían sufir cambios por cambiar la versión de PHP en sí .. Si que veras que si no ajustas igual la configuración (php.ini) de tu nueva versión .. algunas cosas como por ejemplo sesiones (es típico este caso) no se comportarán igual tus aplicaciones. En otros casos .. puede que alguna función que uses esté en "decreap" (en desuso), pero eso ya te lo avisará PHP en un "Notice o Warning" si corresponde.

Los principales problemas de cambiar versión de PHP .. suelen ser como ya mencioné e insito sobre configuración de PHP en sí. Si en su época instalastes PHP 4.1.2 y nunca viste la configuración de tu PHP .. si ahora instalas una versión más reciente . es probable que algunas directivas puedan cambiar de estado por defecto .. por ejemplo .. session.use_trans_sid .. en tu versión actual de PHP está por defecto a 1 ... y en PHP 4.3.x en adelante sale a 0 .. así que si usas sesiones, ahí se pueden comportar diferente tus aplicaciones (=no funcionar como esperabas). "

Al menos ya todo va quedando más claro...

}]
 
Texto Originalmente Escrito por Sh4dow
Con respecto a mysql, lo que dice Julian es cierto es mejor estar usando las ultimas versiones estables, ah! y un consejo por experiencia personal te recomiendo que uses tablas InoDB, aunque la ultima version de mysql estable creo que usa este tipo de tablas por default , tablas myisam sox, he tenido muchos problemas con ellas puede que sea mas rapidas las consultas con este tipo de tablas, pero de algo si estoy seguro y es que se c a g a n muy facil ademas de que no son transaccionales.
Haz clic para expandir...

Ehem... todo laneros utiliza tablas MyISAM y no hemos tenido problemas..... Es verdad que cuando salió MySQL 4 (creo que fue 4.06) sí habían problemas con las MyISAM, que en cualquier momento fallaban y tenían que ser reparadas... Pero ya ha sido solucionado en las últimas versiones.

Pero en MySQL 3.23.x no ha habido ningún problema en tablas MyISAM.
 
yo colaboro en un motor de busqueda colombiano y hemos tenido bastantes problemas con esas tablas, sobre todo en las que tienen que ver con el correo
 
hicieron bien los desarrolladores de mysql en dejar por defecto las tablas InoDB y no las myisam
 
Advantages of transaction-safe tables (TST):

Safer. Even if MySQL crashes or you get hardware problems, you can get your data back, either by automatic recovery or from a backup + the transaction log.

You can combine many statements and accept these all in one go with the COMMIT command.

You can execute ROLLBACK to ignore your changes (if you are not running in auto-commit mode).

If an update fails, all your changes will be restored. (With NTST tables all changes that have taken place are permanent)
Can provide better concurrency if the table gets many updates concurrently with reads.

Advantages of not transaction-safe tables (NTST):

Much faster as there is no transaction overhead.
Will use less disk space as there is no overhead of transactions.
Will use less memory to do updates.

cada uno tiene derecho a escoger lo que mejor le parezca, jusguen ustedes :)
 
Nosotros no hemos tenido ningún problema... ni de rendimiento ni de pérdida de datos....


Tendré que hacer algunos benchmarks de lectura, escritura haber si me decido a convertir las tablas a inodb
 
no, es que las myisam en rendimiento si son mejores pero en integridad de informacion las inodb superan las myisam
 
no, pero si laneros funciona bien asi como esta es mejor que lo dejes asi jeje, nosotros fue porque nos empezaron a surgir los problemas entonces toco cambiar
 
Ups, no soy muy experto pero lo que hago es que guardo en la
BD el pass ,el login y un tipo de usuario, de acuerdo al tipo restrinjo agunas partes de la informacion

Esto es lo que hago no se si este correcto.

<?php
session_start();
include("../claseskds/enusuario.php");
$obj = new enususario();
if ($login && $pass)
{
$link=conectar();
if($link)
if($obj->validacion($link,$login,$pass))
{
if(!session_is_registered("login") ||
!session_is_registered("pass"))
{
$id_se=inicio_sesion($pass,$link);
session_register("login","pass");
}
$tipo=tipos($pass,$link);
session_register("tipo");
if($tipo=='administracion')
include("administracion.htm");
if($tipo=='operador')
include("operador.htm");
}
else
{
include ("error.htm");
}
}
else
{
include ("error.htm");
}
?>
 
Estado
Cerrado para nuevas respuestas.

Los últimos mensajes

Los últimos temas

Arriba Pie
Atrás