Librería User.js (1). Registro de usuarios

publicado en: Diseño web | 0

La mayor parte de las páginas web orientadas a servicios deben implementar un sistema de registro e identificación de usuarios. Varias veces he tenido que desarrollar o modificar el código asociado y debo admitir que, aunque simple, resulta engorroso. Al tratarse de una parte tan crítica de la aplicación, es necesario comprobar muchos detalles: duplicidad de nombres, contraseñas seguras, permitir su restauración, evitar inyección de código, etc. Para el último proyecto, he decidido poner un poco de orden. Aunque iré dando más detalles conforme lo vaya desarrollando, primeramente voy a describir algo tan preliminar como la gestión de usuarios. Construiremos una librería en JavaScript para su manejo, que creo que puede resultar útil a otros por lo común de la necesidad, y de paso sirve de excusa para introducir algunos conceptos interesantes. Para quien se encuentre algo perdido, he escrito también una breve introducción a la programación web. Dicho esto, comenzamos.
La gestión de usuarios comprende varias funciones, que se pueden clasificar en el registro, la identificación y la modificación de datos o restauración de contraseñas. Las operaciones deben repartirse entre el código del cliente y el servidor. Es en este último donde de forma efectiva se hacen las comprobaciones convenientes, se inicia y mantiene la sesión, y se trabaja contra la base de datos. Pero del lado del navegador corre parte del manejo de los datos, y es importante una buena presentación y usabilidad. Cuando el usuario accede por primera vez a la web, usualmente dispone de opciones tanto para identificarse como para darse de alta.

Vamos a seguir un orden cronológico, y por tanto comenzamos con el registro. El código de un formulario de registro podría ser como sigue:

Se trata de un formulario inicialmente oculto, para lo cual se ha definido la clase hidden, con el estilo asociado:

Para hacerlo visible, incluimos un botón de registro con identificador login_create y el siguiente código asociado:

Es decir, al pulsar sobre él se llevan a cabo tres operaciones: se oculta la capa donde está el formulario de identificación (el que veíamos en la primera imagen), se muestra el de registro y por último se carga una imagen captcha, que debe generar la URL captcha.php. El uso de un parámetro aleatorio no cumple otro papel que el de forzar al navegador a realizar dicha petición si se recarga la página, en vez de mostrar la que pueda haber guardado en caché.
Hecho esto, estaremos viendo una página de registro al uso (nota: he dejado una presentación casi minimalista, en parte para no desviar la atención de los elementos esenciales):

Antes de considerar el envío del formulario, es conveniente agregarle cierta funcionalidad para hacer varias comprobaciones simples. Una de ellas suele ser la coincidencia de las dos contraseñas; basta, al salir del campo asociado, efectuar la comprobación. Para mostrar las notificaciones de error se han agregado al formulario contenedores en línea (etiquetas span). Un poco de CSS para darles color rojo y algo de jQuery para mostrarlos sirve para llamar la atención sobre el problema existente.

La verificación que acabamos de lleva a cabo se realiza con facilidad en el equipo cliente. Otro asunto es comprobar, por ejemplo, el correo, donde además de asegurar que cumple con la sintaxis adecuada, es preciso asegurar que no esté ya en uso. Para lo primero, se puede usar una expresión regular. Respecto al segundo chequeo, debemos hacer una llamada al servidor. La siguiente función pregunta a la página a.php, que va a ser la encargada de la gestión de usuarios; y lo hace pasando varias variables: a (de acción), con valor “check” para indicar que queremos efectuar una comprobación; item con valor “email”, para decir de qué tipo, y por último el propio correo electrónico. El servidor nos devolverá el texto “1” si el correo está efectivamente en uso y “0” si no es así.

También debe asegurarse un usuario válido, contraseña segura, etc. Estas comprobaciones, por otro lado, no eximen de volverlas a repetir en el lado del servidor una vez se envíe el formulario. Para efectuar dicho envío, vamos a recurrir de nuevo a la URL a.php, pasándole los campos del formulario, además de una variable a con valor “register”. Como ya habréis podido adivinar, esta variable informa al código en el servidor del tipo de acción que se pretende realizar. En el caso concreto del registro, se han planteado tres respuestas: “1” si el resultado es correcto; “2” si no se ha escrito correctamente el captcha, en cuyo caso se pide otro; y “0” si el usuario se empeña en ignorar las comprobaciones que acabamos de mencionar y envía el formulario con errores.

Para hacer las cosas correctamente, todo el tráfico, pero en especial el envío de la contraseña, debería hacerse bajo una conexión segura. Y si todo ha marchado correctamente, el servidor debe enviar un correo electrónico que permita confirmar la cuenta del usuario. En la próxima entrega veremos cómo se debe completar el registro.
Esta entrada continúa en Librería Users.js (2). Identificación.

Recursos asociados:
Librería User.js para gestión de usuarios
Ejemplo de uso de la librería User.js

Brevísima introducción a la programación web

publicado en: Diseño web | 0

Tenía intención de dedicar una entrada a describir una pequeña librería que estoy desarrollando en JavaScript para la gestión de usuarios. Pero mientras la estaba redactando he caído en la cuenta de que a algunos les interesará conocer primero el funcionamiento de la web, aunque sea de forma somera. Por eso he decidido publicar primero esta pequeña introducción. Es muy genérica, porque su objetivo no es servir de tutorial, sino clarificar conceptos. Quien desee profundizar en algún tema, puede seguir los enlaces. Para quien le parezca muy básico, prometo contenido más especializado en posteriores entradas.
Una página web es en el fondo un documento con una estructura especial, de acuerdo a unos estándares recomendados por la W3C. Usualmente se visualiza mediante un navegador, instalado en un equipo cliente. Cuando se teclea una URL, esta aplicación demanda a un servidor los documentos que componen dicha página. El documento principal normalmente se encuentra en formato HTML (si se almacena, su extensión es htm o html), y su esqueleto es como sigue:

El contenido que se visualiza está entre las etiquetas body y la información para el navegador se incluye en el head. Existen etiquetas para codificar los elementos que todos conocemos de la web, sean contenido (imágenes, párrafos, listas), presentación (cajas, menús, formatos) o de carácter funcional (hiperenlaces, formularios). Estas etiquetas pueden contener información adicional, que se recoge mediante atributos. Por ejemplo, el siguiente código representa un párrafo (etiqueta p) en el que se ha insertado un hiperenlace (etiqueta a); su atributo href recoge la dirección de destino.

El documento HTML puede contener cierto código, habitualmente desarrollado en JavaScript, que se incluye en etiquetas script, o bien directamente en atributos relacionados con eventos (onchange, onclick…). Al pulsar el siguiente botón, por ejemplo, se abre una ventana con un mensaje, gracias a la función alert:

La parte estética se controla mediante atributos o etiquetas style, y utiliza un lenguaje especial denominado CSS. En cualquier caso, por cuestiones de higiene, lo ideal es llevar código y estilo a ficheros independientes, con extensiones js y css respectivamente. Para quien quiera profundizar en el HTML dinámico, un recurso muy valioso es la página W3Schools. Injertos como applets de Java o animaciones Flash merecen tratamiento aparte.
Hasta aquí lo que toca a funcionamiento en el equipo cliente. El servidor puede meramente entregar los ficheros que se le demanden o bien generarlos, lo que da funcionalidad a nuestra web. Existe toda una pléyade de lenguajes de este lado, tanto específicos (PHP, ASP) como genéricos (Python, Ruby). A continuación se muestra un fragmento muy simple en PHP que, usando la función echo, devuelve la página que con la que hemos abierto esta introducción.

En muchos casos, se trabaja regularmente con bases de datos donde se almacena la información que se maneja. Por esto, es habitual la siguiente secuencia de operaciones:

  • El navegador demanda una página web, para lo que pasa al servidor cierta información (métodos GET o POST).
  • En el servidor se ejecuta el código correspondiente, que accede a la base de datos para leer o escribir.
  • Tras efectuar la operación, el código del servidor genera la nueva página.
  • El navegador la representa.


Esta secuencia, tal y como se ha descrito, tiene el defecto de tener que recargar nuevamente la página completa en el navegador. Una forma de evitarlo es empleando AJAX (JavaScript asíncrono), efectuando las peticiones desde dentro de una función y actualizando posteriormente el DOM (Modelo de Objetos del Documento). En este caso, el código del lado del servidor no suele generar una página, sino información, codificada en formatos como XML o JSON. Por último, mencionar que existen librerías como jQuery que facilitan mucho la tarea al programador. El siguiente código, por ejemplo, asocia al elemento con identificador “boton” un evento por el cual, cuando se pulsa, se hace una llamada asíncrona al servidor a través de la URL a.php. Se le pasa por el método POST la variable envio1, con contenido “valor1”. Una vez retorna la respuesta del servidor, se muestra ésta en una ventana desplegable.

Hasta aquí esta brevísima introducción a la programación web. Para los recién llegados que estén interesados en profundizar en ella, les recomiendo seguir los enlaces o buscar información adicional, que es fácil encontrar en la red.

Novedades 20150827

publicado en: Comunicaciones, PLC, Seguridad | 0

En un artículo dividido en dos partes (1 y 2), Jay Griffin describe los sistemas instrumentados de seguridad, que son los que deben llevar planta a situación segura bajo condiciones de riesgo, según se haya determinado en un estudio HAZOP. El texto describe los distintos niveles (desde el SIL 1, que asegura una disponibilidad del 90%, al nivel 4, del 99’99%), las aplicaciones, y cómo se lleva esta seguridad a lógica, entradas, salidas e interfaces.
La web Automation ha publicado una historia sobre los albores de los controladores lógicos programables (PLC). Por desgracia, aunque el contenido es abierto, no se dan facilidades para su lectura, que debe hacerse desde ordenador desde una interfaz engorrosa. La primera parte (página 19) describe los inicios en los 60, cuando se fraguan los ingredientes para la automatización (placas impresas, control numérico, ordenadores analógicos, terminales de vídeo). De ahí al papel de Modicon, Struthers-Dunn y por supuesto General Motors, donde los ingenieros de Hydra-Matic lograron sensibles incrementos de la productividad al reemplazar paneles de relés por controladores digitales. La segunda parte (página 18), centrada en los años 70, describe las compañías pioneras y la segunda generación de PLC.
¿Cómo implantar seguridad en lo sistemas de control? Idealmente con comunicaciones a través de VPN. Pero cuando no es posible (limitación de controladores, exigencia de tiempo real…), aún se pueden usar cortafuegos con inspección profunda de paquetes. Eric Byres, Erik Schweigert y Michael Thomas esbozan como emplearla para evitar ataques DoS o filtrar servicios, por ejemplo.
A propósito del eterno problema de las alarmas, Ian Nimmo y Stephen Maddox hacen un esfuerzo por racionalizarlas. Hay que partir de una correcta definición y priorización, pero también establecer unos valores adecuados, trabajar con operadores, plantear alarmas dinámicas, etc. Es interesante el análisis en función del tiempo de respuesta del usuario a la hora de definir límites no arbitrarios.
¿Qué diferencia un PC industrial de un PC? Tim Munro, de SEL, responde a esta pregunta definiendo las características de un equipo robusto: fiabilidad (refrigeración pasiva, discos sólidos), capacidad de servicio (fuentes redundantes, RAID) y disponibilidad. Es también interesante la introducción, que hace un repaso histórico desde el IBM 5534 hasta los hipervisores, pasando por esa época en la que nos pareció que el PLC quedaría destronado por el PC.

Consejos para programar secuencias (4)

publicado en: PLC, SFC | 0

Esta entrada es continuación de Consejos para programar secuencias (3)

  • El proceso no siempre avanza hacia adelante
    La serie no estaría completa sin mencionar el que a mi juicio es el más importante de los consejos. Emparenta con los primeros de la lista, aunque es más genérico. Y como en otros casos, nace de un problema común derivado de una mala concepción de los procesos. Tendemos a plantear el funcionamiento de las instalaciones en condiciones ideales, sin imperfecciones, sin fallas de equipos, en plena producción y sin cambios de condiciones que hagan rechazar los objetivos y reorientar las tareas. Esta visión idílica no se corresponde en absoluto con la realidad. En el día a día saltan los diferenciales, las válvulas fugan, se rompen los transmisores de señal, los finales de carrera se ensucian, hay cortes de tensión… Pero también la producción sale mal y es necesario anularla, o repetir una acción, o se ha agotado una materia prima y hace falta detener todo y reponerla. Incluso más grave, puede ser necesaria una parada de emergencia en caso de accidente. Y justo aquí es donde se distingue un buen técnico o ingeniero de uno mediocre. Una buena programación contempla todas las posibilidades, todos los saltos, y no sólo aquéllos que se definen para la consecución ideal de la secuencia.
    Sin ánimo de ser exhaustivo, quiero anotar los aspectos que considero necesario estudiar:

    • Como he mencionado, los equipos terminan por fallar, más pronto o más tarde. Para cada uno de los pasos habría que plantear el flujo de la secuencia ante fallo de cualquiera de los equipos involucrados. Es una tarea tediosa, pero obligatoria. Una solución que he planteado en el pasado ha sido distinguir entre equipos críticos y no críticos, siempre dentro de un contexto. Con críticos, me refiero a que su fallo puede ocasionar un percance. Tal puede ser, por ejemplo, un caudalímetro del que depende un lazo PID. Ante fallo de un elemento crítico se programa una salida ordenada de la secuencia. Si, en cambio, ésta puede mantenerse detenida en dicho paso a pesar del problema, prefiero dejar la decisión en manos del operario.
    • Ya que estamos, ¿qué libertad tiene el operario? Como mínimo debería poder detener la secuencia en todo instante y en condiciones seguras. Algunos sistemas usan bloques que permiten pausar, avanzar pasos, retroceder o efectuar saltos. Esto, dejado a la ligera, es potencialmente peligroso. Cada posible camino que se permita debería ir acompañado de un estudio de las consecuencias y acciones para evitar accidentes. Tampoco se puede atar de manos al personal de operación. En procesos por lotes, por ejemplo, es frecuente la necesidad de repetir un paso o un conjunto. Supongamos una reacción química que por las circunstancias (temperatura ambiente, calidad de los reactivos) no ha podido completarse. En este caso, como los puntos de chequeo suelen estar bien definidos, se puede incluir la posibilidad de retroceder en la propia secuencia. En otras circunstancias no es posible dar saltos atrás en el proceso, y la única alternativa es detenerlo. Si es así, lo ideal es habilitar dos tipos de parada: una de emergencia y otra ordenada (que puede coincidir con la descrita en el punto previo). Pausas y avances bien definidos serían un plus del desarrollo.
    • Un error simple, pero habitual: si de una secuencia dependen subsecuencias, hay que estudiar las evoluciones conjuntas. Es decir, hay que ver cómo se comportan las subsecuencias si se interrumple la principal, o si se avanza saltándose sus inicios. También merece consideración el sentido opuesto: qué hay que hacer con la secuencia principal si falla una de las hijas.
    • Cuando los equipos admiten más de una forma de control (manual/automático, local/remoto, interno/externo), nos enfrentamos a una complejidad añadida, ya que en cualquier momento un agente ajeno a la secuencia puede tomar el mando de algún equipo y operarlo de forma no prevista. Por supuesto, también la secuencia debería adaptarse a esta acción a priori no contemplada. Inicialmente puede parecer un obstáculo difícil de salvar, pero si se han seguido correctamente los pasos previos, en realidad el trabajo estaría hecho. No hay diferencia entre un equipo que no arranca por un fallo, por ejemplo, o porque el operador lo haya inhabilitado. Tampoco entre una condición que se satisface por las operaciones definidas en la secuencia o por causas ajenas.

Estas son mis recomendaciones para quienes se inicien en la programación de secuencias. En definitiva, se puede resumir lo más importante de su contenido en una regla de oro: programar a la defensiva. Es la única forma de obtener un resultado de calidad capaz de afrontar los contratiempos.

Novedades 20150810

Harry Forbes, analista de ARC, considera los beneficios que la incorporación de procesadores multinúcleo va a aportar a la automatización. El más importante, aunque no el único como da a entender el título, es la posibilidad de virtualización, tanto de controladores como de los propios dispositivos de campo. Otra posibilidad que me ha parecido muy interesante es correr simultáneamente un sistema operativo en tiempo real con otro “enriquecido” en funciones.

Para quien quiera profundizar en los protocolos existentes para redes de sensores inalámbricos, Mark Nixon, de Emerson, ha publicado una extensa comparativa entre dos de los más usados, WirelessHART y ISA100.11a. Resumiendo mucho, el primero se introduce como una extensión de HART, mientras que el segundo es más flexible, relegando buena parte de la configuración (e indefiniciones) al usuario final.

Me gusta el sistema de recetas de los S7-1200. En particular, la administración mediante páginas web servidas por el propio PLC, lo que permite, por ejemplo, gestionar y supervisar el proceso desde una tablet, bastante útil cuando se trabaja en campo.

El ingeniero de proceso Béla Lipták define cinco niveles de control en la automatización. Hay que aclarar que sólo se refiere a la regulación de magnitudes simples, lo que comúnmente denominamos -generalizando en exceso- un lazo. Los niveles serían, de menor a mayor sofisticación: control manual, con retroalimentación (un PID, por ejemplo), en cascada, anticipativo (con correcciones a la salida) y “dirigido/retrasado” (lead/lag, que prevé variaciones de carga).

Esta semana GE ha lanzado un servicio que puede dar mucho que hablar. Se trata de su propia nube, Predix, desarrollada específicamente para recoger datos generados por sistemas de control. La idea no es nueva (ya lo hacen los termostatos Nest, por ejemplo), pero el empuje que le puede dar GE va a forzar de seguro a otras compañías a invertir en estas tecnologías. Entre otras cosas, Predix promete mayor operatividad e interoperatividad, escalabilidad, y seguridad.

Cuando los valores de proceso no se reciben de periferia integrada, sino a través de comunicaciones, no siempre se dispone de tiempos de muestreo reducidos y constantes; en especial, cuando es vía inalámbrica. Los lazos PID tradicionales no se pueden usar en estas circunstancias. Un PID inteligente, como el PIDPlus, debe tener en cuenta estos tiempos extensos y variables, así como fallos de comunicación.

He descubierto el muy recomendable blog de Juan Carlos Martín Castillo: REEA (Revista de Electricidad, Electrónica y Automática). En él se se puede encontrar gran cantidad de recursos relacionados con sistemas de control. Pero me gustaría destacar la producción propia, en formato videoblog, consistente en tutoriales en los que de forma muy detallada expone casos prácticos, sin renunciar a profundizar en la teoría o herramientas aplica.

1 6 7 8 9 10 11 12