Entorno Drupal del Gobierno de Aragón...Gobierno de Aragón dispone de una plataforma corporativa...

Entorno Drupal del Gobierno de Aragón

Referencia: ESPEC_EspecificacionesTecnicasDrupal.doc

Autor: Aragonesa de Servicios Telemáticos

Fecha de creación: 24/09/2016

Última actualización: 15/11/2016

Versión: v1.0

Clasificación: Uso Público

Especificaciones técnicas para el alojamiento de aplicaciones



Ref.: ESPEC_EspecificacionesTecnicasDrupal.doc Fecha: 15.11.2016 Versión: v1.0

Pág. 2 de 30

Entidad Pública Aragonesa de Servicios TelemáticosAvda. Ranillas 3A • Planta 3ª • Oficina J

50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

Contenido

1. INTRODUCCIÓN................................................................................................................................. 5

2. ARQUITECTURA DE PLATAFORMA TECNOLÓGICA.......... .......................................................... 6

3. ESTRUCTURA DE UN PROYECTO .................................................................................................. 8

4. ESPECIFICACIONES DEL ENTORNO ................... ........................................................................... 9

4.1. CAPA FRONTAL ........................................................................................................................... 9 4.2. CAPA MEDIA ................................................................................................................................ 9

5. ESPECIFICACIONES DE DESARROLLO ................. ...................................................................... 10

5.1. VERSIÓN DE PHP ...................................................................................................................... 10 5.2. CÓDIGO DE APLICACIÓN ......................................................................................................... 10

6. OBLIGACIONES Y RECOMENDACIONES ................. .................................................................... 11

6.1. CODIFICACIÓN .......................................................................................................................... 11

6.1.1. Estándares de codificación ..................................................................................................... 11

6.1.1.1. Identación de línea .............................................................................................................. 11 6.1.1.2. Etiquetas de apertura y cierre en PHP ............................................................................... 11 6.1.1.3. Uso de comillas ................................................................................................................... 11 6.1.1.4. Uso de punto y coma .......................................................................................................... 11 6.1.1.5. Operadores ......................................................................................................................... 12 6.1.1.6. Manejo del array ................................................................................................................. 12 6.1.1.7. Estructuras de Control ........................................................................................................ 12 6.1.1.8. Llamadas a función ............................................................................................................. 13 6.1.1.9. Comentar código ................................................................................................................ 13

6.1.2. Nomenclatura .......................................................................................................................... 13

6.1.2.1. Constantes .......................................................................................................................... 13 6.1.2.2. Funciones ........................................................................................................................... 14 6.1.2.3. Variables globales ............................................................................................................... 14 6.1.2.4. Módulos............................................................................................................................... 14 6.1.2.5. Nombre de los archivos ...................................................................................................... 14

6.1.3. Buenas prácticas ..................................................................................................................... 14

6.1.3.1. Planificar el sitio .................................................................................................................. 14 6.1.3.2. Planificar para el futuro ....................................................................................................... 15 6.1.3.3. Utilizar fragmentos de código PHP con moderación y cuidado.......................................... 15 6.1.3.4. Nunca hackear el núcleo .................................................................................................... 15 6.1.3.5. Evitar hacer hardcoding ...................................................................................................... 15 6.1.3.6. Configurar el sitio utilizando las características .................................................................. 15 6.1.3.7. Asegurarse de que el sitio es seguro ................................................................................. 15 6.1.3.8. Evitar demasiados módulos ................................................................................................ 16 6.1.3.9. Hacer uso de herramientas de accesibilidad y buenas prácticas....................................... 16

6.2. DOCUMENTACIÓN .................................................................................................................... 16

6.2.1. Funciones ................................................................................................................................ 16




Pág. 3 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

6.2.2. Constantes .............................................................................................................................. 17 6.2.3. Módulos ................................................................................................................................... 17

7. RENDIMIENTO ................................................................................................................................. 18

7.1. CACHÉ ........................................................................................................................................ 18

7.1.1. Habilitar cacheo de bloques .................................................................................................... 18 7.1.2. Habilitar cacheo de página ..................................................................................................... 18 7.1.3. Habilitar cacheo de scripts de PHP ........................................................................................ 18

7.2. ESCALABILIDAD ........................................................................................................................ 19

7.2.1. Implementar capas de caché .................................................................................................. 19 7.2.2. Optimizar la base de datos ..................................................................................................... 19 7.2.3. Prevenir bloqueos de base de datos ...................................................................................... 19 7.2.4. Externalizar la búsqueda a una aplicación especializada ...................................................... 20

7.3. MEJORA DE RENDIMIENTO ..................................................................................................... 20

7.3.1. Registro de errores ................................................................................................................. 20 7.3.2. Actualizaciones ....................................................................................................................... 20 7.3.3. Control de la tabla de sesiones ............................................................................................... 20 7.3.4. Carga incorrecta de los diferentes elementos CSS y Javascript. ........................................... 21 7.3.5. Imágenes cargadas en la página. ........................................................................................... 21 7.3.6. Módulos no necesarios. .......................................................................................................... 21

8. SEGURIDAD ..................................................................................................................................... 22

8.1. CONFIGURACIÓN SEGURA DE DRUPAL ................................................................................ 22

8.1.1. Mantener el CORE actualizado .............................................................................................. 22 8.1.2. Instalar únicamente módulos contribuidos seguros ................................................................ 22 8.1.3. Limitar el número de etiquetas permitidas .............................................................................. 22

8.2. AUTORIZACIÓN ......................................................................................................................... 22

8.2.1. Manejar los permisos mediante la función hook_perm() ........................................................ 23 8.2.2. Comprobar los permisos mediante la función user_access ................................................... 23 8.2.3. Evitar la sobrecarga de permisos ........................................................................................... 23

8.3. AUTENTICACIÓN ....................................................................................................................... 24

8.3.1. Seguridad de las contraseñas ................................................................................................ 24 8.3.2. Utilizar el módulo Login Security ............................................................................................. 24 8.3.3. Asegurar las conexiones mediante SSL ................................................................................. 24 8.3.4. No enviar contraseñas por email ............................................................................................ 24

8.4. VALIDACIÓN DE ENTRADAS Y SALIDAS ................................................................................ 25

8.4.1. Usar check_plain() y t() para limpiar los caracteres de las salidas ........................................ 25 8.4.2. Usar la función filter_xss() para proteger de los ataques de Cross-Site Scripting ................. 25 8.4.3. Utilizar la función filter_xss_admin para páginas de administración ...................................... 26

8.5. SISTEMA DE ACCESO EN DRUPAL ........................................................................................ 26

8.5.1. Modificar consultas para el acceso a nodos restringidos ....................................................... 26 8.5.2. Utilizar nodo_access para comprobar los permisos de un nodo específico........................... 27

8.6. SESIONES .................................................................................................................................. 28

8.6.1. Cambiar el tiempo de la expiración de las cookies ................................................................. 28 8.6.2. Cambiar el nombre de la sesión ............................................................................................. 28 8.6.3. Almacenar datos en la sesión ................................................................................................. 28




Pág. 4 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

8.6.4. Requerir cookies ..................................................................................................................... 28

9. REQUISITOS GENERALES ........................... .................................................................................. 29

9.1. COMPATIBILIDAD DE NAVEGADORES Y SISTEMAS OPERATIVOS ................................... 29 9.2. TRATAMIENTO DE PROCESOS PESADOS EN EL SERVIDOR ............................................. 29 9.3. UTILIZAR DRUSH MAKE ........................................................................................................... 29




Pág. 5 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

1. Introducción

Este documento establece las características que desde Aragonesa de Servicios Telemáticos (AST) considera que deben cumplir los portales web desarrollados utilizando le gestor de portales Drupal.

Establece los estándares y buenas prácticas a utilizar en las aplicaciones a desarrollar para asegurar unos requisitos mínimos de calidad y estandarización y una completa compatibilidad con el entorno.

Todas aplicaciones web desarrolladas utilizando el gestor de portales Drupal deberán respetar las características establecidas en este documento. Si se necesitara algún componente, tecnología o herramienta no descrita, AST deberá se r conocedora del hecho y aprobar su uso.

La versión inicial Drupal implementada en Gobierno de Aragón es Drupal 7.33 . Puede obtener información de las versiones existentes en la url https://www.drupal.org/node/3060/release.




Pág. 6 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

2. Arquitectura de plataforma tecnológica

Gobierno de Aragón dispone de una plataforma corporativa de gestión de contenidos para generar webs no colaborativas basada en la solución Drupal para poder alojar webs institucionales excluyendo intranets, webs colabora tivas y grandes portales .

El entorno tecnológico DRUPAL consta del siguiente software:

� BB.DD : MySql 5.5.41

� Servidor web : Apache 2.4.10

� Php : 5.4.35

� Software aplicación : Drupal 7.x

� Licencias aportadas y/o requeridas : --

� Lenguaje de Programación y otras tecnologías: PHP, HTML, CSS, Javascript.

El esquema de la infraestructura en producción es el siguiente:

WebcachePro vlan 710

Mov-drupales-01.aragon.es

CORE Routing

Virtual FWContexto PRO

Balanceador

Fov-apache-01Fov-apache-02

AppPro vlan 719

mov-drupales-01.aragon.local




Pág. 7 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

La nomenclatura de los servidores sigue estos criterios:

CAPA ENTORNO TIPO MÁQUINA

f- frontal

m-medio

o –pro

e –pre

i -integración

f–físico

l – virtual ldom

v-virtual vmware

De esta forma el prefijo “mov” en mov-drupales-01 sería:

m - Capa Media / o - Producción / v - Virtual

La siguiente tabla muestra la relación de los productos instalados divididos por capa en el entorno de producción:

Descripción Componente (arquitectura) Máquina Sistema

operativo Descripción detallada

Capa f rontal Apache 2.2.15 fov-apache-01, fov-apache-02

Red Hat Enterprise Linux 6.4 (x86_64)

Apache Web Server con ProxyPass

Capa media Apache 2.4.10 PHP 5.4.35 MySql 5.5.41

mov-drupales-01 Red Hat Enterprise Linux 6.4 (x86_64)

Apache web server con PHP 5.4.35 y MySql 5.5.41 con server MPM prefork para instalación de Drupales




Pág. 8 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

3. Estructura de un proyecto

El código ha de estar organizado para identificar fácilmente qué hace exactamente. La estructura por defecto de una instalación Drupal es la siguiente:

Directorio Descripción

includes/ Directorio con librerías de funciones comunes que Drupal utiliza.

misc/ Directorio con ficheros javascript, iconos e imágenes utilizables en la instalación de Drupal.

modul es/ Directorio con módulos del core. Los nuevos módulos se deben añadir en el directorio sites NUNCA aquí.

profiles/ Contiene diferentes perfiles de instalación para un site. Si existen otros perfiles (además del default) en este directorio, Drupal preguntará qué perfil desea instalar cuando se instale por primera vez el site hecho con Drupal. El objetivo de un perfil de instalación es habilitar automáticamente ciertos módulos (del Core o contribuidos) de Drupal.

scripts/ Directorio con scripts para tareas del tipo: control de la sintaxis, limpiar el código, arrancar Drupal desde la línea de comandos manejando casos especiales como el cron o test suites (nuevos en Drupal 7).

sites/default/files/ Subdirectorio de sites que almacena los ficheros subidos -y por tanto que en algún momento será servido-al sitio. Debe tener permisos de lectura/escritura para el servidor.

themes/ Directorio con plantillas y temas por defecto de Drupal. Si se añaden nuevos temas debe hacerse en sites/all/themes NUNCA aquí .

authorize.php Script que administra operaciones sobre ficheros autorizados, como por ejemplo instalar temas o módulos de drupal.org.

cron.php Script para ejecutar tareas periódicas como cálculo de estadísticas o limpieza del log de la base de datos.

install .php Script que hace de inicio para el instalador de Drupal.

update.php Script que modifica el esquema de la base de datos después de una actualización de la versión de Drupal.

robots.txt Implementa por defecto la exclusión standard de robots.

Se creará la siguiente estructura de carpetas bajo las propias de temas (/sites/all/themes/) y módulos (/sites/all/modules/):

� contrib : poner cada proyecto contribuido que descargue.

� custom : para incluir código propio agrupados organizadamente en carpetas.

� features : si se usa el módulo Features para exportar la configuración a código, se colocará aquí (esta carpeta no es necesaria como subcarpeta de temas).

� hacked : si se hackea un proyecto contribuido y no se dispone de otra manera de rastrear los parches se deben mover los módulos a esta carpeta.

Se agruparán los módulos personalizados en base a la funcionalidad que proporcionan.




Pág. 9 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

4. Especificaciones del entorno

A continuación se detallan las características de la capa frontal y media, fundamentales para el desarrollo y despliegue de aplicaciones.

4.1. Capa frontal

Está compuesta de dos servidores Apache HTTP Server 2.2 con ProxyPass, que redirigen a la capa media. La distribución de máquinas por entorno es la siguiente:

Entorno Máquinas

Integración fiv-apache-01.aragon.local

Preproducción fev-apache-01.aragon.local, fev-apache-02.aragon.local

Producción fov-apache-01.aragon.local, fov-apache-02.aragon.local

4.2. Capa media

Está compuesta de un servidor Apache versión 2.4.10 con PHP 5.4.35 y MySql 5.5.41 instalados. La distribución de máquinas por entorno es la siguiente:

Entorno Máquina

Integración miv-drupales-01.aragon.local

Preproducción mev-drupales-01.aragon.local

Producción mov-drupales-01.aragon.local

Los subdominios DNS están definidos de forma que las URLs de las aplicaciones sean las siguientes, dependiendo si se debe habilitar o no el acceso por seguro:

Entorno APACHE

Integración http://desaplicaciones.aragon.es/[app] https://desaplicaciones.aragon.es/[app]

Preproducción http://preaplicaciones.aragon.es/[app] https://preaplicaciones.aragon.es/[app]

Producción http://aplicaciones.aragon.es/[app] https://aplicaciones.aragon.es/[app]

En caso de necesitar una URL diferente debe contactar con Aragonesa de Servicios Telemáticos.

Si dispone de un subdominio [app].aragon.es las urls de las aplicaciones tendrán el siguiente formato: http(s)://[des|pre][app].aragon.es . En caso que no tenga y sea necesario, puede solicitarlo -previa justificación- al Servicio de Administración Electrónica para su autorización administrativa.




Pág. 10 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

5. Especificaciones de desarrollo

Previamente al desarrollo de una nueva aplicación deberá asegurarse de que se está en posesión de la última versión disponible del documento de especificaciones.

5.1. Versión de PHP

La versión de PHP instalada en todos los entornos es la 5.4.35. Puede encontrar más detalle sobre la configuración y las extensiones habilitadas en el Anexo “Configuración PHP” de este mismo documento.

NOTA: si su aplicación requiere de una extensión que no está instalada en el servidor, debe ponerse en contacto con AST antes de solicitar el despliegue de la misma. Tenga en cuenta que es posible que no se autorice dicha extensión, lo que implicaría trabajo adicional en el desarrollo. Se recomienda el uso de las extensiones instaladas exclusivamente.

5.2. Código de Aplicación

Toda aplicación desplegada en los servidores del Gobierno de Aragón debe estar registrada en la base de datos de “Gestión de la configuración” (CMDB). Por ello, es necesario que el código de aplicación sea único y el nombre suficientemente descriptivo para poder identificarla.

NOTA: El código será alfanumérico, preferiblemente de 3 ó 4 caracteres y, generalmente, estará formado por las iniciales del nombre de la aplicación. Será acordado entre la empresa desarrolladora y el grupo de [email protected] al comienzo del proyecto.




Pág. 11 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

6. Obligaciones y recomendaciones

6.1. Codificación

6.1.1. Estándares de codificación

La comunidad de desarrolladores de Drupal ha establecido unos estándares sobre codificación y construcción (https://www.drupal.org/docs/develop/standards/coding-standards), basados en PEAR Coding standards (http://pear.php.net/manual/en/coding-standards.php ) que permiten obtener un código estructurado y legible. Se emplean una serie de normas o pautas para formatear el código fuente de una manera común para todos los desarrolladores.

Existe un módulo llamado "coder" que permite comprobar si el código de los módulos desarrollados cumple con los estándares de codificación de Drupal.

6.1.1.1. Identación de línea

El código debe tener dos espacios en blanco para la identación, que no sean tabulaciones. Nunca se debe dejar espacios en blanco al final de cada línea, para continuar en la siguiente línea simplemente presionar la tecla <ENTER>.

6.1.1.2. Etiquetas de apertura y cierre en PHP

En Drupal se utilizan los siguientes principios para el manejo de las etiquetas de apertura y cierre de código PHP:

� Siempre se utiliza la etiqueta de apertura <?php

� La etiqueta de apertura simplificada, <? nunca debe usarse

� Debe utilizarse la etiqueta de cierre, >? . En los archivos .module y .inc se puede omitir la etiqueta de cierre siempre y cuando se esté trabajando solo con php. Omitir la etiqueta de cierre evita que queden líneas en blanco lo que podría dar como resultado un error típico: "Cannot modify header inforamticon - header already sent by ..".

6.1.1.3. Uso de comillas

Se utilizan comillas simples ('texto') o comillas dobles ("tex to") para delimitar las cadenas . Las comillas dobles permiten interpretar el valor de una variable.

“<h1>$title</h1>” el resultado sería el valor de la variable $title.

6.1.1.4. Uso de punto y coma

Siempre se deben finalizar las líneas de código PHP con el punto y c oma .




Pág. 12 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

6.1.1.5. Operadores

Todos los operadores binarios (se utilizan entre dos valores), deben tener un espacio de separación entre ellos , aplica a operadores como +, -, *, /, =, ==, !=, <, >, ., .=, +=, +-, etc.

$numero = 3;

Los operadores unarios como el ++ y el -- no deben tener separación

$numero++;

6.1.1.6. Manejo del array

Los arrays están formateados con espacios separados para cada elemento y cada operador de asignación . El operador => debe separarse por un espacio a ambos lados. Si el bloque de array tiene más de 80 caracteres, cada elemento debe moverse a su propia línea.

$some_array = array('hello', 'world', 'foo' => 'bar '); $fruit['basket'] = array( 'apple' => TRUE, 'orange' => FALSE, 'banana' => TRUE, 'peach' => FALSE, );

6.1.1.7. Estructuras de Control

Las estructuras de control son instrucciones que controlan el flujo de la ejecución de un programa, como instrucciones condicionales y bucles. Las instrucciones condicionales son if, else, elseif, y switch mientras que como control de bucles tenemos are while, do-while, for, and foreach. Las estructuras de control deben mantener un espacio simple entre la palabra clave (if ...) y el paréntesis de apertura que visualmente los distingue de las llamadas a una función. La llave de apertura debe estar en la misma línea que la palabra clave. Siempre se debe usar las llaves de apertura y cierre .

if (condición_1 || condición_2) { acción_1; } elseif (condición_3 && condición_4) { acción_2; } else { acción predeterminada; }

Las estructuras else y elseif deben ir en líneas aparte, debajo del cierre de la estructura, en este caso debajo de la llave de cierre.

if ($a && $b) { sink(); } elseif ($a || $b) { swim(); } else { fly(); }




Pág. 13 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

6.1.1.8. Llamadas a función

En las llamadas a funciones debe existir un espacio simple con el operador (=,<,>,etc...) y no existir espacios entre el nombre de la función y el paréntesis de apertura de la función. Tampoco hay espacio entre el paréntesis de apertura y el primer parámetro. Los parámetros se separan con una coma y un espacio .

$var = foo($bar, $baz);

Si una función utiliza valores por defecto para algunos parámetros, se deben listar estos parámetros

function foo($qux, $bar = 'baz') { $value = $qux + some_function($bar); return $value; }

6.1.1.9. Comentar código

Se debe diferenciar entre los comentarios para aclarar determinados bloques de código -ya que se pueden colocar donde se crea necesario- y los comentarios de documentación -son los que se escriben al principio del archivo, o antes de declarar alguna función-. Estos últimos son sumamente importantes ya que por medio de una API se genera la documentación de ayuda desde las etiquetas que se emplean.

En el tipo de documentación para aclarar algún bloque de código se utiliza las etiquetas de apertura /* y de cierre */ , entre ellas se pueden colocar varias líneas de nuestro comentario, o se podrían utilizar las etiquetas // para un comentario de una simple línea .

// comentario de una simple línea /** * Comentario de varias * líneas de texto */ function system_init() { // Otro comentario de una sola línea ... mi bloque de código }

6.1.2. Nomenclatura

6.1.2.1. Constantes

Siempre escribir en mayúsculas los nombres de las constantes, si éstas se componen de varias palabras separarlas con guiones bajos. Se debe colocar de prefijo –en mayúsculas también- el nombre del módulo o tema al que pertenece.

<?php /** * The current system version. */ define('VERSION', '7.10');




Pág. 14 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

/** * Minimum supported version of PHP. */ define('DRUPAL_MINIMUM_PHP', '5.2.4'); ?>

6.1.2.2. Funciones

Los nombres de las funciones deben estar escritas en minúsculas y las palabras separad as por un guion bajo . Siempre escribir como prefijo el nombre del módulo, tema, etc para evitar así generar nombres duplicados. Después del nombre del módulo, la función debe nombrarse con el verbo y el objeto a los que atañe.

function mymodule_munge_some_text() { ... }

Las funciones de tipo privadas siguen esta convención pero empiezan por un guion bajo.

6.1.2.3. Variables globales

Si se necesitara definir variables globales deben comenzar con el nombre con un guion bajo seguido por el nombre del módulo o tema y otro guion bajo antes del nombre de la variable.

global $_forum_pagina_foros;

6.1.2.4. Módulos

Por norma general, el nombre de un módulo nunca debe incluir guiones bajos , aunque este se componga de varias palabras, para evitar conflictos de espacios de nombres.

mimodulo

6.1.2.5. Nombre de los archivos

Los nombres de los ficheros deben ser en minúsculas . La excepción es para los ficheros de documentación, que deben ser todo en mayúsculas y con la terminación .txt:

CHANGELOG.txt INSTALL.txt README.txt

6.1.3. Buenas prácticas

6.1.3.1. Planificar el sitio

Una buena representación esquemática de la página (wireframes) y una planificación adecuada pueden evitar muchos problemas y malentendidos posteriores.




Pág. 15 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

6.1.3.2. Planificar para el futuro

Es recomendable revisar el sitio y evaluar si es necesario hacer un a adaptación cada vez que sale una versión nueva de Drupal.

6.1.3.3. Utilizar fragmentos de código PHP con moderación y cuidado

Drupal ofrece un gran potencial y flexibilidad al utilizar código PHP en bloques. Si existe algún error de sintaxis en un fragmento de código PHP copiado, cuando Drupal trate de evaluarlo fallará y el sitio web no funcionará . O peor aún, si se introduce una porción de código PHP de un usuario no autorizado se puede exponer todo el sitio web a los ataques de los hackers.

6.1.3.4. Nunca hackear el núcleo

El núcleo hace referencia a todos los archivos que pertenecen a la instalación original de Drupal, es decir, todos los archivos a excepción de los que se encuentran en la carpeta sites. Se pueden añadir perfiles de instalación al directorio profiles pero no se deberá modificar ninguno de los archivos existentes en ese directorio. El motivo es que tras realizar cambios en el núcleo se hará casi imposible aplicar actuali zaciones de Drupal con normalidad . Y algunas de ellas pueden ser importantes, como por ejemplo actualizaciones para corregir fallos de Seguridad. También cabe la posibilidad de dejar el sitio vulnerable a exploits.

6.1.3.5. Evitar hacer hardcoding

Hacer cambios en el código fuente puede ocasionar problemas muy diversos . De todos modos, a veces, como desarrollador de Drupal puede ser necesario retocar el código.

En caso de necesitar cambios del código fuente, debe ponerse en contacto con Aragonesa de Servicios Telemáticos.

6.1.3.6. Configurar el sitio utilizando las características

En Drupal 7, la configuración y los ajustes del sitio son exportables utilizando el módulo de terceros CTOOLS. Las características de este módulo ofrecen un método para empaquetar estos exportables en una nueva función de módulo descargable. Drush CTools Export Bonus ofrece una forma más ligera para exportar la configuración del sitio.

Las características de los módulos facilitan el trabajo con la configuración de los ajustes proporcionando medios cómodos para empaquetar, exportar e importar ajustes para muchos de los módulos de Drupal más utilizados. El uso de las características cambia el paradigma de desarrollo de sitios de pequeños ajustes aquí y allí por la habilitación de características.

6.1.3.7. Asegurarse de que el sitio es seguro

La guía de seguridad de Drupal tiene una sección dedicada a la seguridad de tu sitio con una lista útil de elementos sobre los que trabajar. El módulo Security Review proporciona una revisión automática de posibles problemas de seguridad.




Pág. 16 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

6.1.3.8. Evitar demasiados módulos

Si hay demasiados módulos instalados estos pueden ralentizar el sitio . Además, los módulos que tienen un mal mantenimiento y que contienen errores pueden resultar perjudiciales para la seguridad y la estabilidad. Es importante investigar los módulos de terceros mejor mantenidos antes que instalar un gran número de módulos distintos.

6.1.3.9. Hacer uso de herramientas de accesibilidad y buenas prácticas

Se aconseja la lectura de Drupal Accessibility Statement. A continuación, aquí hay algunas cosas para hacer que tu sitio de Drupal sea más accesible:

� Empezar con la Lista de comprobación de Accesibilidad.

� Seleccionar buenos temas o crearlos propios.

� Elegir módulos de terceros accesibles.

� Identificar problemas de accesibilidad, comunicarlos y enviar, probar y/o solicitar parches.

� Validar los contenidos.

� Asegurar que la diferencia en color no es la única forma de transmitir información significativa.

� Al seleccionar esquemas de color, asegurar que hay suficiente contraste entre el texto o imágenes significativas y el fondo para que personas con visibilidad reducida puedan ver el texto y las imágenes claramente.

6.2. Documentación

A continuación se van a ofrecer una serie de recomendaciones para documentar el código para desarrollar en Drupal.

6.2.1. Funciones

Cuando se documenta una función, la documentación del bloque debe ir situado justo encima de la función que se documenta y sin que existan lí neas en blanco . Un bloque de documentación tiene la siguiente estructura:

/** * Añade botones pro defecto aun formulario. * * @ingroup forms * @see system_settings_form_submit() * @param $form * un array asociativo que contiene la estructura d el formulario. * @return * La estructura del formulario. */ function system_settings_form($form) { ... }




Pág. 17 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

6.2.2. Constantes

Las constantes deberían ser en letras mayúsculas, su nombre completo, con separadores de guiones bajos entre la diferenciación de palabras. Es buena práctica explicar para qué va a ser usada la constante .

/** * Identificador de rol para usuarios autenticados. Debe coincidir con algún valor de la tabla de roles. */ define('DRUPAL_AUTHENTICATED_RID', 2);

6.2.3. Módulos

Previamente a declarar las funciones es recomendable definir de forma breve qué es lo que realiza el módulo , para ello utilizar el siguiente formato:

/** * @file * Describir brevemente la funcionalidad que es cub ierta por el módulo. * * Un párrafo o dos que definan a grandes rasgos s obre su módulo y cómo se comporta */




Pág. 18 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

7. Rendimiento

Para la mejora del rendimiento en desarrollos con Drupal se establecen un conjunto de pautas para conseguir productos eficientes en tiempo y en recursos.

7.1. Caché

Las técnicas de manejo de la memoria caché en soluciones basadas en Drupal pueden proporcionar una mejora sensible del rendimiento .

7.1.1. Habilitar cacheo de bloques

La mayoría de los sitios web de Drupal poseen bloques, los más típicos son los menús, listas, formularios y búsqueda. Algunos de estos bloques son particularmente lentos. Para acelerar su sitio, se ha de instalar módulos que habiliten el cacheo de bloques para crear versiones en caché de los más lentos.

7.1.2. Habilitar cacheo de página

Por defecto, Drupal construye una nueva página web para cada visitante. Si dos visitantes piden la misma página, Drupal la construye dos veces. Al habilitar la caché de página se almacena en memoria caché la página generada por Drupal la primera vez que se construye. En posteriores visitas se devuelve la página guardada en vez de construir todo de nuevo.

Unos valores apropiados en webs cuyos contenidos no se actualizan constantemente podrían ser:

� Mínimo de permanencia en caché: 9 horas

� Caducidad de las páginas en caché: 1 día

El almacenamiento en caché de Drupal está desactivado por defecto y debe configurarse.

7.1.3. Habilitar cacheo de scripts de PHP

Se recomienda utilizar un acelerador de PHP .

De forma predeterminada, Drupal compila cada vez que un visitante carga una página web del sitio. Volver a compilar una y otra vez es redundante. En cambio, cuando está instalado un acelerador de PHP en caché, el motor de PHP Drupal compila sólo una vez y guarda los resultados en la caché de escritura. La próxima vez que es necesario el programa, el nuevo motor utiliza el script compilado en la memoria caché.




Pág. 19 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

7.2. Escalabilidad

Se deben tener en cuenta las formas de escalar soluciones basadas en Drupal, antes de alcanzar una situación límite que provoque una degradación del rendimiento.

Una de las mayores dificultades comienza cuando se rebasa un umbral de visitas significativo. Los objetivos de una buena escalabilidad en Drupal deben considerar que:

� Para aumentar la funcionalidad se requiere que las piezas de Drupal integradas puedan seguirse extendiendo de forma simple, que se pueda actualizar a nuevas versiones sin tener que reescribir mucho código y poder incluir nuevas piezas sin mayor dificultad.

� Para aumentar el almacenamiento de datos o peticiones , se tiene que prever que todo servidor tiene unos límites y si las expectativas de crecimiento superan las capacidades reales de la arquitectura hay que analizar y proponer soluciones como aumentar el nº de servidores, configurarlos correctamente, redimensionar la BBDD…

7.2.1. Implementar capas de caché

Se deben implementar capas de caché para los contenidos estáticos , de este modo se ahorrarán muchos recursos y se agilizará la respuesta de la web.

7.2.2. Optimizar la base de datos

Se deben implementar optimizaciones de configuración para el rendimiento de base de datos e índices, por ejemplo:

� Asegurar que no se sobrecarga la base de datos más allá de lo que puede soportar. La fórmula para calcular las máximas conexiones que se pueden servir y por tanto, las consultas simultáneas que se pueden encolar, se determina con la siguiente fórmula:

global_buffer + (thread_buffer * max_connections)

� Activar la caché de la base de datos para que las consultas repetitivas se resuelvan desde los resultados almacenados en la caché.

� Monitorizar las consultas que más tiempo están tardando en resolverse para poder analizarlas y determinar los problemas de ejecución.

7.2.3. Prevenir bloqueos de base de datos

En algunas ocasiones se producen errores y desviaciones entre escrituras y lecturas respecto a la media, y las configuraciones por defecto empiezan a degradar el funcionamiento. Un ejemplo es que las tablas están pensadas para recibir el 95% de lecturas y el 5% de escrituras y si se rompe esa regla, se producirán bloqueos de consultas que pondrán al límite la cola de consultas de la base de datos.




Pág. 20 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

7.2.4. Externalizar la búsqueda a una aplicación es pecializada

Una de las funcionalidades que degrada los recursos de la base de datos y que pone en riesgo la estabilidad de la aplicación es la búsqueda que viene integrada dentro del núcleo de Drupal. El módulo “Search” que viene en el paquete oficial, es un buen módulo cuando el volumen de datos no supera los 10.000 nodos y máximo 1000 v isitas por día . La indexación de los nodos está almacenada en la tabla “search_index” de la base de datos y como consecuencia cada búsqueda le genera consultas costosas de procesar. La solución es implementar un motor de búsqueda independiente que puede ayudarnos rápidamente a ahorrar muchas consultas a nuestra base de datos.

7.3. Mejora de rendimiento

Se debe hacer uso de las técnicas disponibles para mejorar el rendimiento de sitios web basados en Drupal.

7.3.1. Registro de errores

El registro de errores y/o alertas debe cambiarse de “dblog” (BBDD) a “syslog ” (S.O.).

7.3.2. Actualizaciones

Se debe desactivar el módulo de verificación de actualizaci ones (update manager).

7.3.3. Control de la tabla de sesiones

Es necesario controlar la tabla de sesiones de usuario. Para ello es recomendable hacer un buen uso del recolector de sesiones que permita eli minar sesiones antiguas y mantener un tamaño adecuado de la tabla .

Si un site tiene miles de visitas diarias, esta tabla crece de forma significativa. Es recomendable realizar limpieza de la misma para que su manejo sea más eficiente en términos de rendimiento.

En la configuración de Drupal puede encontrarse algo como esto:

ini_set('session.gc_maxlifetime', 200000); // 55 ho urs (in seconds)

Esto indica que el recolector de basura comienza a trabajar cada 55 horas, lo que indica que si un usuario no se ha logado en ese tiempo, su sesión es eliminada. Si la tabla de sesiones crece desmesuradamente es recomendable reducir el tiempo para la aparición del recolector. Un ejemplo sería el siguiente:

ini_set('session.gc_maxlifetime', 86400); // 24 hou rs (in seconds) ini_set('session.cache_expire', 1440); // 24 hours (in minutes)

Que ajusta session.gc_maxlifetime, a 24 horas y además ajusta también el tiempo de expiración de la cache al mismo tiempo.




Pág. 21 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

7.3.4. Carga incorrecta de los diferentes elementos CSS y Javascript.

7.3.5. Imágenes cargadas en la página.

Es necesario evitar la carga de imágenes muy pesadas adaptando su visualización al medio.

7.3.6. Módulos no necesarios.

Es necesario retirar los módulos que no se estén usando .




Pág. 22 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

8. Seguridad

8.1. Configuración segura de Drupal

En este punto se van a comentar las vulnerabilidades más comunes a las que se enfrenta un administrador de Drupal. Se van a especificar una serie de pautas a tomar y las prácticas que deben seguir para proteger el sitio y mitigar las debilidades .

8.1.1. Mantener el CORE actualizado

Una de las cosas más importantes para proteger el sitio es estar al día con las nuevas versiones del código . Es un proceso de dos pasos:

� Aprender acerca de las actualizaciones

� La aplicación de las actualizaciones

8.1.2. Instalar únicamente módulos contribuidos seg uros

Introducir modulo contribuidos por otros desarrolladores en la aplicación sólo si se puede asegurar que el módulo contribuido es seguro , de esta manera se evita introducir agujeros de seguridad en el código original. Existen varios indicadores a considerar para evaluar la cohesión de un módulo:

� ¿Es popular el módulo? Si hay muchos usuarios utilizando el modulo implica que se hayan realizado muchas revisiones sobre el código y lo hace más seguro.

� ¿Es experimentado el creador del módulo? Incluso los más experimentados codificadores pueden introducir los puntos débiles en sus módulos, pero hay menos posibilidades de que esto ocurra si el desarrollador del módulo tiene mucha experiencia en Drupal

� ¿Ha tenido problemas de seguridad en el pasado? esto es muy importante a la hora de calcular el riesgo del módulo, asegúrese de que estos agujeros han sido superados

8.1.3. Limitar el número de etiquetas permitidas

Por defecto, Drupal provee dos tipos de entrada: Filtered HTML y Full HTML. La configuración de la entrada por defecto (Filtered HTML) permite a los usuarios insertar ciertas etiquetas con parámetros conocidos que son difíciles de explotar por ataques XSS o CSRF.

8.2. Autorización

Se debe realizar una correcta gestión de los permisos de acceso a los mó dulos para mejorar la seguridad en Drupal.




Pág. 23 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

8.2.1. Manejar los permisos mediante la función hoo k_perm()

Es recomendable proteger los accesos a las funciones críticas de lo s módulos mediante permisos . Se debe establecer una jerarquía de permisos de acceso.

La función hook_perm() permite a todos los módulos que puedan añadir permisos para su administración. Por ejemplo, el código siguiente para el módulo "blog" perteneciente al Core de Drupal:

function blog_perm() { return array(‘create blog entries’, ‘delete own b log entries’, ‘delete any blog entry’, ‘edit own blog entries’, ‘edit a ny blog entry’); }

Crear un nuevo permiso para el módulo es tan simple como añadir una nueva entrada en el array que se retorna. Un ejemplo de la implementación en el módulo node:

function node_perm() { $perms = array(‘administer content types’, ‘adminis ter nodes’, ‘access content’, ‘view revisions’, ‘revert revisions’, ‘de lete revisions’); foreach (node_get_types() as $type) { if ($type->module == ‘node’) { $name = check_plain($type->type); $perms[] = ‘create ’. $name .‘ content’; $perms[] = ‘delete own ’. $name .‘ content’; $perms[] = ‘delete any ’. $name .‘ content’; $perms[] = ‘edit own ’. $name .‘ content’; $perms[] = ‘edit any ’. $name .‘ content’; } } return $perms; }

8.2.2. Comprobar los permisos mediante la función u ser_access

La función user_access(), puede ser llamada con solo un parámetro para que compruebe si se tiene permiso para ejecutar una función , como se puede ver en el siguiente ejemplo:

if (user_access(’Tiene permiso’)) { // El código solo se ejecuta si el usuario tiene pe rmiso }

La función comprueba que el usuario tenga el permiso y devuelve un booleano que permite la ejecución o impide la misma del trozo de código. El parámetro que se le pasa a la función es el permiso requerido. También pueden comprobarse los permisos establecidos para un usuario:

if (user_access(’administer nodes’, $account)) { return TRUE; }

8.2.3. Evitar la sobrecarga de permisos

En general, la configuración de administración de permisos se debe usar en pequeños módulos o módulos donde el control debe ser dado sólo a los usuarios muy potentes.




Pág. 24 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

Una buena práctica es crear un permiso independiente para todas las activ idades relacionadas con las características de administrac ión que se podrían utilizar para tomar el control de un servidor, tales como envío de archivos, la ejecución de comandos, la salida de filtrado y la ejecución de PHP.

8.3. Autenticación

La autenticación nativa de Drupal crea algunos problemas de seguridad que deben ser abordados. La configuración y uso cuidadoso de los módulos adicionales pueden ayudar a mitigar estas vulnerabilidades. Todos los sitios que utilizan la autenticación nativa Drupal deben ser conscientes de los peligros potenciales e imponer las siguientes configuraciones para garantizar máxima flexibilidad y la seguridad del esquema de autenticación de Drupal.

8.3.1. Seguridad de las contraseñas

Hacer uso del módulo Password Strength para aumentar la seguridad de las contraseñas . Este módulo habilita el uso y requiere el uso de contraseñas fuertes. Con el uso de contraseñas fuertes, su sitio Drupal será más resistente a los ataques de fuerza bruta y a los robos de contraseña.

8.3.2. Utilizar el módulo Login Security

El módulo de Drupal Login security se puede utilizar en todo los sitios. El modulo avisa a los administradores cuando existen fallos en los intent os de autenticación e impone un retraso en para cada nuevo intento. Después de un número determinado de intentos puede bloquear la cuenta sobre la que se intenta acceder. Este módulo puede prevenir los ataques de adivinación de contraseñas contra los sitios Drupal y supervisar los inicios de sesión para alertar a los administradores de problemas potenciales antes de las quejas de los usuarios.

8.3.3. Asegurar las conexiones mediante SSL

Debe utilizar SSL sobre las conexiones a su sitio Drupal para evitar que las credenciales del usuario de inicio de sesión estén expuestas a los usuarios maliciosos que observan el tráfico.

8.3.4. No enviar contraseñas por email

Por defecto Drupal transmite las contraseñas de las cuentas por correo electrónico. Esto suele suceder cuando se crea una nueva cuenta de usuario. La plantilla predeterminada de correo electrónico enviado a los usuarios incluye el nombre de usuario, contraseña y un enlace a una página de un tiempo de inicio de sesión. Debido a que el usuario puede utilizar el enlace en tiempo de una entrada no hay ninguna razón real para enviar la contraseña por correo electrónico. El peligro en el envío de contraseñas a través del correo electrónico es que el correo electrónico se transmite generalmente a través de canales no cifrados y una vez entregada es propenso a la pérdida debido a una cuenta comprometida de correo electrónico, la pérdida de dispositivos móviles, etc Con el fin de mitigar esta amenaza es importante eliminar la contraseña que se encuentran en cada pl antilla de correo electrónico .




Pág. 25 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

8.4. Validación de entradas y salidas

A continuación se presenta un conjunto de pautas para facilitar el manejo de la información de entrada y salida de las aplicaciones desarrolladas en Drupal. Se van a ofrecer una serie de recomendaciones para evitar las vulnerabilidades más conocidas sobre este aspecto.

8.4.1. Usar check_plain() y t() para limpiar los ca racteres de las salidas

Es recomendable utilizar estas funciones check_plain() y t() para limpiar el formato de los mensajes de salida . La función check_plain() debe usarse cada vez que tenga texto no confiable y sobre el que no quiere realizar ninguna marca.

Además debe usarse junto con la función t() que proporciona una manera de construir cadenas seguras de texto mediante tokens para sustituciones (placeholders tokens) que soportan prefijos que le indican como actuar. Un ejemplo sería el siguiente:

drupal_set_message(t('Your favorite color is @color ', array('@color' => $color)); // Note que la clave en el array (@color) es lo mis mo que reemplazar el token en la cadena. Your favorite color is brown.

El prefijo @ le comunica a t() que el valor está siendo reemplazado mediante el token a través de la función check_plain().

8.4.2. Usar la función filter_xss() para proteger d e los ataques de Cross-Site Scripting

Cross-site scripting (XSS) es una forma común de ataque que permite insertar su propio código sobre la web, lo que puede ser usada para provocar errores y mal funcionamiento de la misma La función filter_xss() protege al código contra esta vulnerabilidad de la siguiente manera:

� Comprueba que el texto filtrado está en formato UTF-8

� Elimina caracteres como NULL

� Se asegura que las etiquetas HTML y sus etiquetas atributos están bien formadas.

� Se asegura las entidades HTML como & están bien formadas

� Asegura que no existen etiquetas HTML que contengan protocolos no permitidos.

Un ejemplo de uso sería el siguiente:

** * Process variables for aggregator-item.tpl.php. * * @see aggregator-item.tpl.php */ function template_preprocess_aggregator_item(&$vari ables) { $item = $variables['item']; $variables['feed_url'] = check_url($item->link); $variables['feed_title'] = check_plain($item->tit le); $variables['content'] = aggregator_filter_xss($it em->description); ... }




Pág. 26 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

Existe una llamada a aggregator_filter_xss(), que es un wrapper sobre filter_xss() y ofrece un array con las etiquetas HTML aceptables .Una versión simple de este wrapper sería:

/** * Safely render HTML content, as allowed. */ function aggregator_filter_xss($value) { $tags = variable_get("aggregator_allowed_html_tag s", '<a> <b> <br> <dd> <dl> <dt> <em> <i> <li> <ol> <p> <strong> <u> <ul>'); // Turn tag list into an array so we can pass it as a parameter. $allowed_tags = preg_split('/\s+|<|>/', $tags, -1 , PREG_SPLIT_NO_EMPTY)); return filter_xss($value, $allowed_tags); }

8.4.3. Utilizar la función filter_xss_admin para pá ginas de administración

Es recomendable filtrar elementos de las pantallas de administració n con la función filter_xss_admin para evitar ataques XSS.

A veces es necesario que un módulo genere HTML para páginas de administración, además de ser protegidas por controles de acceso se puede utilizar la función filter_xss_admin(). Es un contenedor para filter_xss() con una lista liberal de etiquetas permitidas, incluyendo todo, excepto <script>, <objeto>, y las etiquetas <style>. En este ejemplo, la “misión” del sitio sólo se puede establecer desde una página de administración a la que sólo usuarios de administración de la configuración del sitio tienen permiso de acceso, por ello podría definirse de esta forma:

if (drupal_is_front_page ()) ( $ Misión = filter_xss_admin (theme_get_setting ("mi sión")); )

8.5. Sistema de acceso en Drupal

El sistema de acceso de Drupal se basa en una sola tabla de la base de datos (node_access) y dos funciones de acceso a los principales (db_rewrite_sql y node_access). Como su nombre indica, db_rewrite_sql realiza una consulta y lo modifica, vuelve a escribir, para incluir las condiciones adecuadas para limitar los elementos de contenido que un usuario puede ver. La función node_access es a la vez una envoltura (wrapper) alrededor de los datos de la tabla de la base node_access y un método para invocar los ganchos en los módulos que definen nodos para comprobar que no existen restricciones de acceso.

El sistema de acceso del nodo de Drupal es un siste ma de permisos en lugar de un sistema de prevención .

Se van a realizar una serie de recomendaciones sobre el sistema de acceso de Drupal

8.5.1. Modificar consultas para el acceso a nodos r estringidos

Es necesario asegurar las consultas sobre módulos restringidos c on db_rewrite_sql .

Se tiene como ejemplo una página principal de Drupal que tiene una lista de nodes y links que llevan al contenido de los citados nodos. Imagine que está instalado el modulo Private y se han creado dos nodos, el nodo1 visible para todos los usuarios y el nodo 2 que tiene el acceso restringido mediante el modulo Private. La consulta para listar los nodos de la página principal es ejecutada en el pager_query:




Pág. 27 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

SELECT DISTINCT(n.nid), n.sticky, n.created FROM node n WHERE n.promote = 1 AND n.status = 1 ORDER BY n.sticky DESC, n.created DESC LIMIT 0, 10

Después de habilitar y configurar el modulo Private, la consulta se reescribe para incluir los limites. Estas condiciones específicas son añadidas por un usuario que no es el autor del módulo, por lo que puede que se le deniegue el acceso al nodo

SELECT DISTINCT(n.nid), n.sticky, n.created FROM node n INNER JOIN node_access na ON na.nid = n .nid WHERE (na.grant_view >= 1 AND ( (na.gid = 0 AND na.realm = 'all’) OR (na.gid = 0 AND na.realm = 'private_author’))) AND ( n.promote = 1 AND n.status = 1 ) ORDER BY n.sticky DESC, n.created DESC LIMIT 0, 10

En la primera consulta, sólo las condiciones aseguran que los nodos son promocionados desde la página de inicio y publicados. En la segunda consulta, hay un conjunto mucho más complejo de condiciones y un join a la tabla node access. Se pueden especificar las condiciones después, pero db_rewrite_sql está modificando la consulta para añadir controles para mostrar sólo los nodos que debe permitir el usuario.

Se debe agregar una restricción al menú para que sólo los usuarios con el permiso para la administración de los nodos puedan acceder a la página e introducir una condición WHERE para chequear que el nodo esta publicado:

$results = db_query(“SELECT n.nid, n.title, nr.body FROM {node} n INNER JOIN {node_revisions} nr ON n.vid = nr.vid WH ERE n.status = 1“);

Lo siguiente sería envolver la consulta con una llamada a db_rewrite_sql:

$results = db_query(db_rewrite_sql(“SELECT n.nid, n .title, nr.body FROM {node} n INNER JOIN {node_revisions} nr ON n.v id = nr.vid WHERE n.status = 1“));

Ahora cuando la consulta es ejecutada por un usuario sin privilegios, se transforma para que contenga los límites propuestos.

8.5.2. Utilizar nodo_access para comprobar los perm isos de un nodo específico

La función db_rewrite_sql es una solución para obtener listado s de nodos , pero para determinar qué usuario tiene acceso a un nodo específico es más fácil simplificar utilizando la función node_access:

$node = node_load(arg(2)); if (node_access(’view’, $node)) { drupal_set_message(check_plain($node->title)); }

Usando node_access es mucho más flexible. El primer parámetro es la operación que se quiere tratar: una vista, actualización, un borrado o un alta.




Pág. 28 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

8.6. Sesiones

Drupal modifica el manejo de las sesiones que realiza PHP. A continuación se van a ofrecer una serie de pautas para manejar las sesiones de dentro de sistemas desarrollados en Drupal.

8.6.1. Cambiar el tiempo de la expiración de las co okies

La longitud del tiempo de expiración de la cookie que contiene el identificador de sesión es controlada por session.cookie_lifetime dentro del archivo de configuración settings.php. Por defecto tienen un valor elevado, es recomendable ponerlo a 0 para destruir la cookie.

Es recomendable destruir la cookie cuando un usuario cierra el navegador.

8.6.2. Cambiar el nombre de la sesión

La generación automática del nombre de la sesión puede evitarse eliminando el comentario de una línea en settings.php y especificando el valor de la variable $cookie_domain. El valor debe contener sólo caracteres alfanuméricos . La sección correspondiente del settings.php es:

/** * Drupal automatically generates a unique session c ookie name for each site * based on on its full domain name. If you have mul tiple domains pointing at * the same Drupal site, you can either redirect the m all to a single domain * (see comment in .htaccess), or uncomment the line below and specify their * shared base domain. Doing so assures that users r emain logged in as they * cross between your various domains. */ # $cookie_domain = 'example.com';

Es recomendable generar nombre de sesiones diferentes para cada subdominio.

8.6.3. Almacenar datos en la sesión

Si la información es transitoria y no importa si se pierde, o si se necesita almacenar datos a corto plazo para los usuarios anónimos, se puede almacenar en la sesión. Si se desea vincular una preferencia permanente a la identidad de usuario, se almacena en el objeto $user.

La variable $user no debe ser utilizada para almacenar información para los usuarios anónimos.

8.6.4. Requerir cookies

Si el navegador no acepta cookies, no puede establecerse una sesión debido a que la directiva PHP, sessions_use_only_cookies, se ha establecido en 1 y la alternativa (pasando el PHPSESSID en la cadena de consulta de la URL) se ha desactivado mediante la creación sessions.use_trans_sid a 0. Esta es una buena práctica, según lo recomendado por el framework Zend

Para disuadir a los secuestros de sesión, el identificador de sesión se debe regenerar cuando un usuario inicia sesión.




Pág. 29 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

9. Requisitos generales

Los requisitos generales de las aplicaciones web desarrolladas son los siguientes:

9.1. Compatibilidad de navegadores y sistemas opera tivos

� Los portales web deben ser compatibles con los navegadores más utilizados hoy en día. En todo momento hay que evitar código que pueda provocar problemas de incompatibilidad entre navegadores diferentes e incluso entre diferentes versiones del mismo navegador.

� El portal debe funcionar correctamente en clientes Windows y clientes Linux.

9.2. Tratamiento de procesos pesados en el servidor

En algunas ocasiones los portales web requieren la ejecución de procesos que pueden llegar a consumir muchos recursos de máquina (memoria y procesador) y cuya ejecución se puede alargar durante bastante tiempo, como pueden ser: procesos de cálculo complejo, consultas masivas de datos, creación de listados…

La ejecución de estos procesos de forma interactiva suele provocar problemas como:

� la perdida de timeout de la sesión web

� problemas con los sistemas de filtrado, seguridad, y/o balanceo de carga que puedan existir en la interconexión entre el cliente y el servidor.

� penalización del rendimiento del servidor y en consecuencia penalización del rendimiento de las aplicaciones desplegadas.

Si la aplicación requiere de la ejecución de algún proceso con estas características, es necesario que ofrezca al usuario una forma alternativa de ejecución que no ocasione los problemas anteriormente mencionados, y lance el proceso en “segundo plano” , e incluso en su caso pudiese derivarlo a otro servidor que llevaría a cabo el proceso.

A su vez deberá implementarse un “proceso de notificación” , de forma que cuando el proceso haya finalizado se le comunique al usuario de alguna forma. En ese momento el usuario de la aplicación podrá acceder o consultar los resultados de la ejecución del proceso.

9.3. Utilizar Drush Make

Drush Make es una funcionalidad que permite por un lado crear archivos de instalación, en los cuales se indiquen los módulos que se deben instalar; por otro lado permite ejecutar estos archivos de instalación para que automáticamente se descargue Drupal junto los módulos indicados. El beneficio principal es facilitar y automatizar la tarea de descarga de módulos cuando se inicia un nuevo proyecto, ahorrando tiempo al desarrollador al no tener que realizar esta tarea de forma manual.




Pág. 30 de 30


50018 • ZARAGOZATel. 976 71 4495 • Fax. 976 71 4145

www.aragon.es

Permite:

� Crear un archivo de los módulos y temas que interesen.

� Crear una copia de un nuevo sitio con dichos módulos y temas.

� Además de los módulos y temas, incluye la estructura de carpetas.

No es necesario guardar todos los módulos contribuidos versionados, sólo el fichero generado con Drush Make.

Entorno Drupal del Gobierno de Aragón...Gobierno de Aragón dispone de una plataforma corporativa...

Documents

Transcript of Entorno Drupal del Gobierno de Aragón...Gobierno de Aragón dispone de una plataforma corporativa...