2009-12-11 10 views
5

Hasta ahora he estado manejando las sesiones de los usuarios con las cookies del lado del cliente y las entradas de la base de datos.tratando de forma segura las "sesiones" del cliente en PHP

Cuando el usuario inicia sesión, genero un guid y lo coloco en una cookie en la computadora del cliente. Luego creo una entrada en una tabla MySQL de "sesiones" y agrego el guid, la dirección IP, el nombre de usuario, los privilegios, etc. Luego, cuando el usuario accede a la página, compruebo si hay una cookie de sesión. si es así, verifico la base de datos para el guid en la cookie y me aseguro de que la dirección IP coincida. Si lo hace, entonces el usuario inicia sesión con el resto de la información en la tabla db. Si algo está mal (dirección IP incorrecta, sesión expirada, etc.) elimino la entrada de la base de datos y elimino la cookie guid.

Nunca antes había usado el $ _SESSION global.

¿Es mi camino una buena práctica o necesito volver a pensar cómo estoy manejando esto?

+1

Estás reinventando la rueda de mi amigo –

Respuesta

7

Parece que usted tiene los fundamentos cubiertos. Sin embargo, si está haciendo todo eso manualmente, entonces simplemente está implementando su propio $_SESSION, y no aprovecha el hecho de que ya puede hacer todo eso por usted.

Si desea utilizar una base de datos para manejar una sesión, puede anular la gestión de sesión predeterminada con la suya. Eche un vistazo al session_set_save_handler(). Lo hago en mis aplicaciones.

class SessionHandler 
{ 

    public function open($save_path, $session_name) 
    { 
     $this->sessionName = $session_name; 
    return(true); 
    } 
    public function close() { 
     //stuff 
    } 

    public function read($id) { 
     $expiretime = date("Y-m-d H:i:s",time() - $this->maxLifeTime); 
     $sql = "SELECT * FROM sessions where sessionid='".$this->db->escapeData($id)."' AND lastupdated>='".$expiretime."' LIMIT 1"; 
    $result = $this->db->query($sql); 
     //etc. 
    } 

    //etc. 

    public function setAsSessionHandler() 
    { 
    session_set_save_handler(
     array($this,'open'), 
     array($this,'close'), 
     array($this,'read'), 
     array($this,'write'), 
     array($this,'destroy'), 
     array($this,'gc') 
    ); 
    } 
} 

$sessionHandler = new SessionHandler(); 
$sessionHandler->setAsSessionHandler(); 

Usted puede tener toda la funcionalidad que acaba de describir que ha implementado mediante el uso de esto, pero todavía tienen el poder de $ _SESSION que lo haga por usted.

Por ejemplo, si desea agregar una comprobación de IP para ver si la sesión sigue siendo válida antes de iniciarla, puede agregarla como parte de la función "abrir". Si quisiera escribir los datos de la sesión en diez bases de datos diferentes (no como lo haría), podría lograr esto en la función 'escribir'.

Esas funciones se usan en función de cómo usa $ _SESSION, y al ponerlas en una clase simple, puede administrar cómo funciona de manera muy efectiva.

Verá que la identificación de la sesión es un parámetro que se pasa a las funciones de lectura/escritura/destrucción, y seguirá administrándolo de la misma forma con la rutina de generación de GUID.Sin embargo, puede pegar la generación de guid y las comprobaciones en esta clase de administrador de sesiones y simplemente hacer que la función abrir() las haga. Centralizado, sin muss, sin complicaciones.

1

La forma en que lo está haciendo ahora es bueno si de alguna manera necesita vincular al usuario actual con otra información de base de datos.

Usar sesiones es la forma preferida de hacerlo por simplicidad. Le sugiero que lea un poco al respecto en www.php.net/sessions y tome una decisión al respecto. Es muy fácil de usar, pero es menos flexible que usar una tabla de base de datos. Todavía puede establecer todos los valores que necesita, pero luego tendrá que buscarlos e insertarlos en la consulta cada vez que necesite usarlos para las operaciones de la base de datos.

+0

que es un buen punto, pero creo que la clase de controlador de sesión de zombats hace que la porción de la base de datos de sesiones sea un poco más perfecta. –

1

Creo que está en el camino correcto. Realmente va a depender de los requisitos de seguridad de su aplicación. Puede pensar en $ _SESSION muy similar a $ _COOKIE: como un mecanismo para proporcionar estado entre actualizaciones de página. En este contexto, la identidad de tu usuario. Su base de datos debe proporcionar mecanismos de autenticación adicionales. Cosas que pueden identificar a su usuario de manera única. Una suposición típica es la dirección IP, pero ¿qué sucede si alguien IP cambia? El agente de usuario es otra posibilidad, pero estos no son muy únicos.

que sugeriría un vistazo a: http://php.net/manual/en/session.security.php

+0

creo que la dirección IP es lo suficientemente bueno, especialmente porque la mayoría de las personas están detrás de los routers de todos modos, y que la propiedad intelectual no suele (en mi experiencia) actualizar a menos que el router se reinicia, generalmente junto con un mecanismo interno para actualizar la IP. Además, incluso si la actualización del IP del usuario fuera un factor serio, todo lo que significaría es que el usuario debe volver a iniciar sesión; además, en mis propias implementaciones, generalmente hago que la sesión caduque en alrededor de tres o cuatro horas. –

+0

Eso es todo muy cierto. Estaba pensando más acerca de los clientes móviles. Si su sitio va a ser accedido por un teléfono, si esa persona está en movimiento, hay muchas más posibilidades de que cambie el IP. Aún así, esta es una porción bastante pequeña del tráfico web para la mayoría de las personas. – Brad

+0

Además, si busca una integración perfecta de $ _SESSION con su base de datos, consulte el componente Zend_Auth de Zend Framework. – Brad

Cuestiones relacionadas