Posts Tagged Instancias

Autenticar un usuario en Zend Framework – Identificar usuario

Siguiendo el hilo del apunte anterior vamos a ver como identificar un usuario una vez programado el adaptador.

El componente Zend_Auth implemente el patrón Singleton de diseño. Esto quiere decir que en todo momento sólo tendremos una instancia de esta classe y que para obtenerla deberemos utilizar su método estático getInstance(). La instancia de Zend_Auth será la que utilizaremos para identificar al usuario una vez obtengamos sus datos.

Formulario para identificar

Para identificar un usuario, en nuestro caso, nos hace falta conocer su nombre de registro (nickname, mail o lo que se utilice) y su contraseña. Con un formulario estándar nos bastará:
<form action="/authentication/login" method="post">
<input type="text" name="username"/>
<input type="password" name="pwd"/>
</form>
Podemos observar que el formulario apunta al controlador AuthenticationController y la acción loginAction. Aquí es dónde identificaremos el usuario.

Identificar el usuario en el controlador

Para identificar al usuario deberemos implemetar la acción loginAction dentro del controlador que se encargue de identificar a los usuarios (no tiene por qué ser AuthenticationController). Veamos un ejemplo:
<?php
class RegisterController extends Zend_Controller_Action{
...
public function loginAction(){
require_once('/path/to/AuthenticationAdapter.php');
$auth = Zend_Auth::getInstance();
/* Comprovaciones de que $_POST['username'] y
* $_POST['pwd'] existen */
if(/* Existen y cumplen las restricciones*/){
$adapt = new AuthenticationAdapter($_POST['username'], $_POST['pwd']);
$res = $auth->authenticate($adapt);
if($res->getCode() == Zend_Auth_Result::SUCCESS){
/* Esta línea es muy importante porqué es la que nos grabará los datos que hemos
* introducido en la variable $sessionData (en el post anterior) en la session */
$auth->getStorage()->write($result->getIdentity());
}
}
}
A partir de aquí se puede diferenciar más el comportamiento del sistema en función del $res->getCode() por ejemplo. Un switch-case nos puede servir para diferenciar un error en el nombre de usuario o en la contraseña.

Consultar si un usuario está identificado

Una vez identificado el usuario y guardados los datos que queremos (session) tendríamos que poder acceder a esta información desde cualquier punto del sistema. Esto se puede hacer a través del método hasIdentity() del componente Zend_Auth. Veamos un ejemplo de como lo utilizaríamos si quisiéramos redirigir a la página principal un usuario que no está identificado:
/* En alguna action que no queremos que los usuarios no identificados vean */
$auth = Zend_Auth::getInstance();
if($auth->hasIdentity()==true){
/* Si está identificado guardaremos los datos
* que pusimos en $sessionData en la variable $identity */
$identity = $auth->getIdentity();
}else{
/* Si no está identificado lo redirigimos al document root */
$this->_redirect('/');
}
Espero que a partir de aquí podais identificar vuestros propios usuarios :) Os dejo la dirección del manual de referencia del Zend Framework porqué, una vez llegados a este punto, las posibilidades que tenemos con Zend_Auth son enormes.

Si teneis alguna duda ya sabeis, comentad!

, , , , ,

No Comments

Amazon premia la planificación

Nos lo avanzaba Santi el sábado por la mañana en su post (a mi a las ocho menos cuarto por mail, que afortunado me siento!). Amazon a abierto una fórmula de contratación para instancias de EC2 alternativa al pago por uso que existía hasta ahora (que sigue estando disponible).

La nueva fórmula premia los clientes que hagan una buena planificación del consumo de recursos que van a realizar. Así, siempre que tengamos activa una instancia más de 143 días al año (24 horas al dia) nos va a salir a cuenta esta nueva fórmula de pago por avanzado. El sistema se basa en una cuota fija por uno o tres años y un precio mucho más reducido por uso (horas de instancia activa).

Este ahorro, que puede parecer un poco escaso a primera vista, es muy significativo en máquinas de altas prestaciones que debamos tener activas 24/7 todos los días del año. Veamos un ejemplo:

  • Las instancias del tipo High-CPU Extra Large Tienen un coste de 0.80 $/hora (para Unix/Linux) en la antigua fórmula de contratación. Con estos datos el coste anual de esta máquina si nunca la detuviéramos sería de:
    0.80 $/h * 24 h/dia * 365 dias/año = 7,008 $/año
  • En el nuevo sistema de pago estas instancias tienen un coste de 0.24 $/hora y una cuota anual de 2,600 $. Con estos datos el coste de esta máquina sería el siguiente:
    0.24 $/h * 24h/dia * 365 dias/año + 2,600 $/año = 4,702.4 $/año

Podemos discutir si esta nueva fórmula es adecuada o no para partes del sistema que requieran una flexibilidad mayor en cuanto a número de instancias activas, pero un 33% de ahorro para máquinas “estáticas” es una buena noticia, Sin duda.

, , , ,

3 Comments