Entorno LAMP

Entorno LAMP 2016 del
Gobierno de Aragón
Especificaciones técnicas para el
alojamiento de aplicaciones
Referencia: AST-ESPEC-
EspecificacionesTecnicasLAMP2016.doc
Autor: Aragonesa de Servicios Telemáticos
Fecha de creación: 08/08/2016
Última actualización: 09/11/2016
Versión: v1.0
Clasificación: Uso Público

Entorno LAMP 2016 del Gobierno de Aragón
Contenido
1. INTRODUCCIÓN ................................................................................................................................. 5
2. ARQUITECTURA DE PLATAFORMA TECNOLÓGICA .................................................................... 6
3. ESTRUCTURA DE UN PROYECTO................................................................................................... 8
3.1. DIRECTORIOS GENERALES COMUNES A TODOS LOS TIPOS DE PROYECTO .................. 8
3.1.1. Directorio docs/.......................................................................................................................... 8
3.1.2. Directorio src/ ............................................................................................................................ 8
3.1.2.1. Directorio php/ ....................................................................................................................... 9
3.1.2.2. Directorio conf/ ...................................................................................................................... 9
3.1.3. Directorio setup/ ........................................................................................................................ 9
3.1.3.1. Manual de instalación............................................................................................................ 9
3.1.3.2. Scripts de BBDD ................................................................................................................. 10
3.1.4. Ficheros estáticos y temporales .............................................................................................. 11
4. ESPECIFICACIONES DEL ENTORNO ............................................................................................ 12

4.1. CAPA FRONTAL ......................................................................................................................... 12
4.2. CAPA MEDIA............................................................................................................................... 12
4.3. CAPA BACK O DE BASE DE DATOS ........................................................................................ 13
4.3.1. Configuración de BBDD .......................................................................................................... 13
5. ESPECIFICACIONES DE DESARROLLO ....................................................................................... 15

5.1. VERSIÓN DE PHP ...................................................................................................................... 15
5.2. CÓDIGO DE APLICACIÓN ......................................................................................................... 15
5.3. VERSIÓN DE LA APLICACIÓN .................................................................................................. 15
5.4. CARPETAS DE LA APLICACIÓN EN EL SERVIDOR WEB ...................................................... 16
5.5. USO DE NUEVOS FRAMEWORKS ........................................................................................... 17
5.6. INTEROPERABILIDAD ............................................................................................................... 17
5.7. LOGS ........................................................................................................................................... 17
5.8. GESTIÓN DE USUARIOS ........................................................................................................... 17
5.8.1. Usuarios de aplicación ............................................................................................................ 17
5.8.2. Usuarios de Base de Datos ..................................................................................................... 18
5.9. DEFINICIÓN/CREACIÓN DE BASE DE DATOS........................................................................ 18
6. OBLIGACIONES Y RECOMENDACIONES ..................................................................................... 19

6.1. CODIFICACIÓN .......................................................................................................................... 19
6.1.1. Guía de estilo de código .......................................................................................................... 19
6.1.2. Estilo ........................................................................................................................................ 20
6.1.2.1. Indentación .......................................................................................................................... 20
Ref.: AST-ESPEC-EspecificacionesTecnicasLAMP2016.doc Entidad Pública Aragonesa de Servicios Telemáticos

Fecha: 09.11.2016 Av. Ranillas, 3 A, 3ª Oficina J • 50018 ZARAGOZA
Versión: v1.0 Pág. 2 de 53 Tel. 976 71 4495 • Fax. 976 71 4145
www.aragon.es
6.1.2.2. Longitud de la línea ............................................................................................................. 20

6.1.2.3. Terminación final ................................................................................................................. 20
6.1.2.4. Demarcación de código en PHP ......................................................................................... 20
6.1.2.5. Manejo de cadenas ............................................................................................................. 20
6.1.2.6. Manejo del Array ................................................................................................................. 21
6.1.2.7. Llamadas a función ............................................................................................................. 21
6.1.2.8. Estructuras de control ......................................................................................................... 21
6.1.3. Nomenclatura .......................................................................................................................... 22
6.1.3.1. Clases.................................................................................................................................. 22
6.1.3.2. Clases Abstractas ............................................................................................................... 22
6.1.3.3. Interfaces ............................................................................................................................. 22
6.1.3.4. Nombre de ficheros ............................................................................................................. 22
6.1.3.5. Funciones y Métodos .......................................................................................................... 22
6.1.3.6. Variables.............................................................................................................................. 23
6.1.3.7. Constantes .......................................................................................................................... 23
6.1.4. Ficheros ................................................................................................................................... 23
6.1.4.1. Nomenclatura de ficheros ................................................................................................... 23
6.1.4.2. Subida de ficheros ............................................................................................................... 24
6.1.4.3. Bibliotecas ........................................................................................................................... 24
6.1.5. Gestión de dependencias ........................................................................................................ 24
6.1.5.1. Composer y Packagist ........................................................................................................ 24
6.1.5.2. PEAR ................................................................................................................................... 25
6.1.6. Verificaciones SonarQube ....................................................................................................... 25
6.1.6.1. Crítica .................................................................................................................................. 25
6.1.6.2. Mayor................................................................................................................................... 27
6.1.6.3. Menor .................................................................................................................................. 31
6.1.6.4. Info....................................................................................................................................... 32
6.1.7. Buenas prácticas ..................................................................................................................... 32
6.1.7.1. No sobrecargar métodos ..................................................................................................... 32
6.1.7.2. No usar funciones dentro de bucles de conteo ................................................................... 32
6.1.7.3. Declarar los métodos estáticos ........................................................................................... 32
6.1.7.4. Utilizar la variable $_SERVER [ ’REQUEST_TIME’ ] ......................................................... 33
6.1.7.5. Utilizar foreach() en los bucles de colecciones y arrays ..................................................... 33
6.1.7.6. Utilizar strpos() para las búsquedas de subcadenas .......................................................... 33
6.1.7.7. Realizar preincremento de las variables ............................................................................. 33
6.1.7.8. Realizar depuraciones de código ........................................................................................ 33
6.1.7.9. Variables globales ............................................................................................................... 33
6.2. DOCUMENTACIÓN .................................................................................................................... 34
6.2.1. Ficheros ................................................................................................................................... 34
6.2.2. Clases ...................................................................................................................................... 34
6.2.3. Funciones ................................................................................................................................ 34
6.3. BASES DE DATOS ..................................................................................................................... 35
6.3.1. Extensiones ............................................................................................................................. 35
6.3.1.1. MySQL extensión ................................................................................................................ 35

www.aragon.es
6.3.1.2. PDO extensión .................................................................................................................... 35

6.3.2. Inyección SQL ......................................................................................................................... 35
6.4. CACHÉ ........................................................................................................................................ 36
6.4.1. Opcode cache ......................................................................................................................... 36
6.4.2. Caché de objetos..................................................................................................................... 36
6.5. SEGURIDAD ............................................................................................................................... 37
6.5.1. Seguridad en aplicaciones web............................................................................................... 37
6.5.2. Password Hashing................................................................................................................... 37
6.5.3. Filtrado de Datos ..................................................................................................................... 37
6.5.4. Gestión de la sesión ................................................................................................................ 38
6.5.4.1. Medidas contra la predicción de sesión .............................................................................. 38
6.5.4.2. Medidas contra la captura del identificador a través de ataques XSS ............................... 38
6.5.4.3. Medidas contra la fijación de sesión ................................................................................... 38
6.5.4.4. Medidas contra el eavesdropping ....................................................................................... 38
6.5.4.5. Medidas contra los errores en el cierre de sesión .............................................................. 38
6.5.4.6. Medidas ante aspectos propios de la implementación de la gestión de sesiones de PHP 39
6.5.5. Validación ................................................................................................................................ 39
6.5.6. Archivos de Configuración ...................................................................................................... 39
6.5.7. Informe de Errores................................................................................................................... 40
ANEXO 1: CONFIGURACIÓN PHP...................................................................................................... 41
ANEXO 2: SECURIZACIÓN DEL ENTORNO ...................................................................................... 50
ANEXO 3: CONVENIO DE NOMENCLATURA DE OBJETOS DE BBDD .......................................... 52

www.aragon.es
1. Introducción
El presente documento define las especificaciones técnicas a seguir por toda aplicación que se
despliegue en la arquitectura LAMP del Gobierno de Aragón.
Con el objetivo de facilitar la labor de desarrollo, integración y despliegue, el documento divide el

escenario en varias partes diferenciadas:
Parte I: Arquitectura. Breve descripción de todos los componentes que forman parte
de la arquitectura del sistema, balanceo, servidor de aplicaciones, capa de datos,..
Parte II: Estructura de un proyecto. Estructura organizativa que deben cumplir los
desarrollos LAMP.
Parte III: Especificaciones del entorno. Configuración del entorno de servidores del
Gobierno de Aragón.
Parte IV: Especificaciones de desarrollo. Directrices que se deben seguir en el

desarrollo de aplicaciones LAMP para albergar desarrollos en los servidores del
Gobierno de Aragón.
Parte V: Obligaciones y recomendaciones. Recomendaciones y fundamentos para la

codificación y aspectos de seguridad en los servidores del Gobierno de Aragón.
El documento va complementado con varios anexos con información más específica a modo de
complemento.

www.aragon.es
2. Arquitectura de plataforma tecnológica

A continuación se detalla la arquitectura tecnológica para la plataforma LAMP en el Gobierno de
Aragón. El objetivo es que antes de comenzar los desarrollos se tenga en cuenta el entorno final,
de forma que se eviten conflictos a la hora de la puesta en producción de las aplicaciones.
Existen 3 entornos disponibles en los que se instalarán las aplicaciones de forma secuencial:
1. Integración: entorno para realizar el primer despliegue de la aplicación, además de

pruebas básicas de funcionamiento.
2. Preproducción: entorno idéntico al de producción que facilitará la realización de las

pruebas previas al paso a producción (integración, validación de usuario, carga, etc.).
3. Producción: entorno final.
El escenario que detallaremos a continuación define la estructura del entorno de producción,

siendo el entorno de preproducción idéntico tanto en componentes como en configuración. Del
mismo modo, el entorno de integración sirve para comprobar que la aplicación funciona
adecuadamente y garantizar que las versiones de los productos coinciden con el escenario que
nos vamos a encontrar en el entorno de producción.
La arquitectura tecnológica del Gobierno de Aragón está organizada en base a una estructura de
3 capas (frontales web, capa media y capa de base de datos).
Diagrama arquitectura LAMP (entorno de producción)

www.aragon.es
La nomenclatura de los servidores sigue estos criterios:
CAPA ENTORNO TIPO MÁQUINA

f- frontal o – producción f–físico
m-media e – preproducción l – virtual ldom
b-back i – integración v-virtual vmware
De esta forma el prefijo “mov” en mov-lamp2016-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:
Componente
Descripción Máquina Sistema operativo Descripción detallada
(arquitectura)
Capa frontal Apache 2.2 fov-apache-01, fov- Red Hat Enterprise Linux 6.4 Apache Web Server con
apache-02 (x86_64) ProxyPass
Capa media Apache 2.4.6 mov-lamp2016-01 Red Hat Enterprise Linux Apache web server con PHP
Server release 7.2 (Maipo) 5.4.16 como módulo
Capa back MariaDB 5.5.47 bov-lamp2016-01 Red Hat Enterprise Linux Servidor MariaDB, puerto
Server release 7.2 (Maipo) 3306

www.aragon.es
3. Estructura de un proyecto
Todo proyecto que se entregue para ser desplegado en los servidores del Gobierno de Aragón
debe tener una estructura determinada y cumplir con una serie de especificaciones que se detalla
a continuación.
3.1. Directorios generales comunes a todos los tipos de proyecto

Existe una serie de directorios que nos vamos a encontrar en todos los tipos de proyectos.
Los directorios que aparecen siempre en los proyectos son:
Directorio Contenido
docs/ Contiene toda la documentación relativa a un proyecto
src/ Dentro de este directorio se incluyen dos subdirectorios:
• “php” donde ubicamos los ficheros fuente

• “conf”, que contendrá los ficheros de configuración a parametrizar por entorno.
setup/ Este directorio contiene ficheros relacionados con la instalación del sistema, por ejemplo, manual de
instalación, ficheros de creación de la base de datos, etc.
NOTA: es imprescindible la entrega de un manual de instalación adecuado a la versión de la

aplicación junto a los ficheros fuentes de la misma.
3.1.1. Directorio docs/
Contiene toda la documentación relacionada con el proyecto: documentación técnica, manuales

de usuario, manual de explotación, etc.
3.1.2. Directorio src/

Este directorio almacena dos carpetas: la carpeta php, que contiene la aplicación web y la
carpeta conf, que contiene la configuración de la misma, parametrizable por entornos.

www.aragon.es
3.1.2.1. Directorio php/
Contiene los fuentes de la aplicación web. Los ficheros ubicados en esta carpeta serán
copiados a la carpeta document root del virtual host de apache en los distintos entornos.
3.1.2.2. Directorio conf/
Dentro de este directorio se distribuirán todos los ficheros susceptibles de parametrización de

un entorno a otro, como por ejemplo, el acceso a fuentes de datos, WebServices o configuración
genérica de la aplicación. Estos ficheros no deben tener un formato determinado, pero sí contener
las propiedades comunes que queremos utilizar en la aplicación, evitando así valores
“hardcodeados” dentro de la misma.
Salvo parámetros que el proveedor desconoce y no pueden ser facilitados, como pueden ser
accesos o contraseñas a distintas URLs de la DGA, todos los demás parámetros deben ser
informados correctamente en cada fichero según el entorno para el que estén definidos.
Estos ficheros se deberán entregar por triplicado, uno por cada uno de los entornos de ejecución
de las aplicaciones (integración, preproducción, producción), de forma que el proveedor entregue
la aplicación una única vez por versión. Desde despliegue, a medida que la aplicación vaya
pasando por los distintos entornos, se ajustarán los parámetros de acuerdo con este y se copiarán
el/los fichero/s dentro de su ruta en src/php (ruta especificada en el manual de instalación).
NOTA: una misma entrega parametrizable se utilizará para el paso de la aplicación por los tres
entornos. En ningún caso se aceptarán para una misma versión entregas diferentes o con alguna
corrección para preproducción o producción.
Cualquier cambio en ficheros que no tenga que ver con la parametrización deberá generar una
nueva versión y, por consiguiente, una nueva entrega.
3.1.3. Directorio setup/

Contiene toda la información para la puesta en marcha de la aplicación. No debe faltar el
siguiente contenido:
3.1.3.1. Manual de instalación
Debe incluir obligatoriamente:
Descripción de la aplicación y pasos para su instalación en cada entorno.
Si es necesario que la aplicación se ejecute bajo http o https.
Instrucciones de creación de directorios en el servidor, como por ejemplo, directorios

de almacenamiento de ficheros temporales.
Explicación de los ficheros de configuración distribuidos bajo el directorio src/conf/ y

valores que es necesario parametrizar para que la aplicación funcione correctamente

www.aragon.es
en los entornos del Gobierno de Aragón. También se indicará la ubicación de los

mismos dentro de src/php.
Creación de alias o directorios virtuales en el servidor web, en caso de ser necesario.
Si se trata de una subida de versión, relación de cambios implementados respecto a

la versión anterior.
NOTA: cualquier relación de dependencia de la aplicación con otros módulos, plataformas

comunes, plataformas de autenticación propias de algún Departamento, directivas específicas a
aplicar en el virtualhost de apache, etc, deberá ser indicada explícitamente en el manual de
instalación.
NOTA: cualquier ausencia de lo indicado anteriormente implicará el rechazo de las peticiones de

despliegue hasta su subsanación.
3.1.3.2. Scripts de BBDD
NOTA: en todas las entregas se deberá incluir un manual con las instrucciones de ejecución de los
scripts, así como las posibles acciones en caso de errores (continuar la ejecución o no, ejecutar
scripts de borrado o regresión, etc...).
Los componentes para la instalación o modificación de la base de datos se proporcionarán en

scripts SQL que deben poder ser re-ejecutados, para lo cual se proporcionarán scripts para el
borrado de los objetos y/o vaciado de tablas.
Es obligatorio proporcionar scripts separados para:
Creación de tablas
Creación de claves ajenas (relaciones)
Creación de índices
Creación de vistas
Creación de triggers
Creación de procedimientos y funciones
Scripts para carga inicial de datos
Otros
NOTA: no se deben incluir scripts para la creación de usuarios. Para tal fin existen formularios de
solicitud de usuarios/bases de datos.

www.aragon.es
3.1.4. Ficheros estáticos y temporales

Si la aplicación necesita directorios para ubicar ficheros generados por la propia aplicación ya
sean temporales o no, debe indicarse en el manual de instalación.
La ubicación de estos ficheros en el servidor se especifica en el apartado “Carpetas de la

aplicación en el servidor web” de este mismo documento.
NOTA: siempre que sea necesario actualizar estos ficheros, deberá indicarse en el Manual de
Instalación de la versión correspondiente.

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.6 con PHP 5.4.16 instalado como módulo. La
distribución de máquinas por entorno es la siguiente:
Entorno Máquina
Integración miv-lamp2016-01.aragon.local
Preproducción mev-lamp2016-01.aragon.local
Producción mov-lamp2016-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 protocolo 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.

www.aragon.es
4.3. Capa back o de base de datos

La capa back se encuentra implementada con MariaDB 5.5.47. El puerto por el cual escucha
MariaDB es el 3306, esto es importante a la hora de configurar la conexión en la aplicación.
NOTA: el valor del puerto nunca debe ir ‘hardcodeado’ en la aplicación, debe incluirse como
parámetro dentro de un fichero de configuración.
La distribución de máquinas por entorno es la siguiente:
Entorno Máquina
Integración biv-lamp2016-01.aragon.local
Preproducción bev-lamp2016-01.aragon.local
Producción bov-lamp2016-01.aragon.local
4.3.1. Configuración de BBDD
Estos son algunas variables de configuración del servidor MariaDB
VARIABLE VALOR
open_files_limit 2500
max_connections 500
innodb_buffer_pool_size 8388608
key_buffer_size 8384512
max_connections 500
tmp_table_size 33554432
have_innodb YES
innodb_data_file_path ibdata1:10M:autoextend
Se han aplicado los siguientes cambios:
Establecidos character_set_database y character_set_server a utf8
El valor de data_dir es /opt/mysql/data
Desactivados los binary_logs
Asignados en el fichero /etc/my.cnf los siguientes valores:
user=mysql
old_passwords=1
lower_case_table_names=1
character-set-server=utf8

www.aragon.es
collation-server=utf8_general_ci
skip-character-set-client-handshake
port=3306
log_slow_queries = slow-queries.log
open_files_limit=2500
max_connections=500
tmp_table_size=33554432

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.16. 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 desplieguelamp@aragon.es al comienzo del proyecto.
5.3. Versión de la aplicación

En la página inicial de la aplicación, deberá hacerse referencia, a modo informativo, a la versión
correspondiente de la misma.

www.aragon.es
5.4. Carpetas de la aplicación en el servidor web

Cada aplicación dispondrá de la siguiente estructura de directorios:
Estructura de directorios asociados a la aplicación dentro del servidor web
Directorio html, corresponde al “document root” del virtual host asociado al sitio. A
este directorio se copiará el contenido de src/php del entregable.
Directorio ficheros, esta carpeta almacenará ficheros generados por la aplicación y

el servidor web tendrá permisos de lectura y escritura sobre ella. La ruta a la carpeta
debe estar parametrizada en el fichero de configuración, siempre y cuando se haga
uso de ella. Distinguiremos entre dos tipos:
Temporales: se almacenarán en la subcarpeta tmp. Son generados y usados

en un momento puntual por la aplicación. Deberán ser eliminados tras su uso
por la misma, de lo contrario, con el paso del tiempo, pueden llegar a ocupar
excesivo espacio en disco y su contenido podría ser susceptible de eliminarse
en tareas de liberación de espacio en disco.
Estáticos: se almacenarán en la subcarpeta datos. Son aquellos que son

generados o no por la aplicación y cuyo uso perdura en el tiempo.
Directorio logs, almacenará los siguientes ficheros:
access.log, registro de accesos de Apache
error.log, registro de errores de Apache.
ssl_access.log, registro de accesos https de Apache, si SSL está activado
ssl_error.log, registro de errores https de Apache, si SSL está activado
php.log, registro de errores php.

www.aragon.es
5.5. Uso de nuevos frameworks

Se permitirá el uso de cualquier framework que cumpla las siguientes condiciones:
Debe ser compatible con la versión PHP 5.4.16.
5.6. Interoperabilidad
Para la realización de webservices, deberán cumplirse las especificaciones marcadas en el
documento “AST-ESPEC-InteroperabilidadTecnicaWS.pdf”.
5.7. Logs
Para cada aplicación, el servidor generará por defecto estos ficheros de log en la ruta app/logs/:
access.log, error.log, ssl_access.log, ssl_errorlog y php.log. Si la aplicación necesita generar logs
adicionales, deberá utilizar un sistema de log que escriba en esta ruta. La rotación de logs es
diaria, de esta forma se tendrá un histórico del log almacenado por día, lo que facilita su consulta
y envío al proveedor en caso de ser solicitados.
NOTA: si la aplicación necesita generar logs específicos, al margen de los generados por defecto,
debe indicarlo en el manual de instalación.
A continuación mostramos la configuración del nivel de log en los distintos entornos:
Entorno Directiva LogLevel (Apache) Nivel log PHP

Integración warn E_ALL & ~E_DEPRECATED & ~E_STRICT
Preproducción warn E_ALL & ~E_DEPRECATED & ~E_STRICT
Producción warn E_ALL & ~E_DEPRECATED & ~E_STRICT
5.8. Gestión de usuarios

En referencia a la gestión de usuarios, distinguiremos entre usuarios de aplicación y usuarios de
base de datos.
5.8.1. Usuarios de aplicación

Para la autenticación/autorización de usuarios en las aplicaciones, alternativamente a la
implementación de un sistema propio, existen varias soluciones con las que integrarse:
LDAP: todo empleado del Gobierno de Aragón dispone de una cuenta en el

directorio LDAP corporativo.
Autoregistro: para escenarios de usuarios externos (ciudadanos/empresas).

www.aragon.es
NOTA: La utilización de estas plataformas deberá solicitarse previamente a AST a través del gestor
de la aplicación e indicarse claramente en el Manual de Instalación de la aplicación.
5.8.2. Usuarios de Base de Datos
La aplicación utilizará por lo general un usuario para conectarse a la base de datos. Este tendrá
asignados una serie de privilegios en función de las necesidades de la aplicación. Será
nombrado con el código de aplicación seguido de “USER” (APP_USER).
Deberá indicarse en el manual de instalación el/los usuarios a crear y los privilegios asociados a
los mismos. El grupo de despliegue se encargará de gestionar la creación de dichos usuarios.
5.9. Definición/Creación de Base de Datos

El conjunto de especificaciones técnicas a tener en cuenta en el diseño físico de la base de
datos se detalla en el convenio de nomenclatura adjunto en el Anexo “Convenio de nomenclatura
de objetos de BBDD”, basado en el código de aplicación que deberá ser solicitado al inicio del
proyecto.

www.aragon.es
6. Obligaciones y recomendaciones
6.1. Codificación
Se deben tener en cuenta los fundamentos indicados por PHP para su codificación cumpliéndose
obligatoriamente al menos los indicados en el apartado “Verificaciones SonarQube” incluidas en
este documento.
6.1.1. Guía de estilo de código
Se ha de adherir a un estilo de código común para facilitar el trabajo de los desarrolladores al

combinar una variedad de librerías para los proyectos.
El Framework Interop Group (antes conocido como el ‘PHP Standards Group’) ha propuesto y
aprobado una serie de recomendaciones de estilo conocidas como PSR-0, PSR-1, PSR-2 y PSR-
4.
Se recomienda escribir código PHP que se adhiera a uno o más de estos estándares. Puede ser
cualquier combinación de PSR, o uno de los estándares de codificación hechos por PEAR o Zend.
Más acerca de PSR-0
Más acerca de los Estándares de Codificación de PEAR
Más acerca de los Estándares de Codificación de Zend
Más acerca de los Estándares de Codificación de Symfony
Para verificar que el código construido cumple estas recomendaciones puede utilizarse
PHP_CodeSniffer y para obtener un análisis en tiempo real pueden usarse plugins para editores
de texto como Sublime Text.
Para modificar la sintaxis de código automáticamente y que quede conforme a estos estándares
puede utilizarse:
PHP Coding Standards Fixer (Fabien Potencier),
php.tools (popularizado como plugin del editor sublime-phpfmt).
Se prefiere la utilización del inglés para los nombres de símbolos e infraestructura del código.

www.aragon.es
6.1.2. Estilo
6.1.2.1. Indentación
La indentación debe consistir en 4 espacios. Las tabulaciones no están permitidas.
6.1.2.2. Longitud de la línea
Lo recomendable es mantener líneas que como máximo tengan de longitud 80 caracteres. Si en

circunstancias especiales no es posible, el tamaño máximo permitido para una línea de PHP es de
120 caracteres.
6.1.2.3. Terminación final
La terminación de la línea sigue la convención del archivo UNIX. Las líneas deben finalizar con un
salto de línea única (LF).
6.1.2.4. Demarcación de código en PHP
No se deben utilizar atajos-uso abreviado de tags. SI los ficheros solo contienen código PHP la
etiqueta de cierre puede ser omitida. El código siempre debe comenzar delimitado por las
etiquetas PHP como en el ejemplo siguiente;
<?php
?>
6.1.2.5. Manejo de cadenas
Literal (no contiene substituciones) se marca la cadena entre comillas simples.
$a = 'Example String';
Cadena que incluye diferentes apóstrofes: debe de marcarse con comillas dobles.
$sql = "SELECT id, name from people WHERE name='Fred' OR name='Susan'";
Substituciones de variables: deben reflejarse de alguna de estas dos maneras
$greeting = "Hello $name, welcome back!";

$greeting = "Hello {$name}, welcome back!";
Concatenación de cadenas: debe utilizar el operador ".". Se debe de añadir un espacio

delante y posteriormente al operador
$company = 'Zend' . ' ' . 'Technologies';

www.aragon.es
Es aconsejable dividir la instrucción en varias líneas para mejorar la legibilidad. En este

caso cada línea utiliza el operador "."
$sql = "SELECT id, name FROM people “

. “WHERE name = 'Susan' “
. “ORDER BY name ASC ";
6.1.2.6. Manejo del Array
Un array con un índice debe de comenzar situando el mismo a 0. No está permitido utilizar
números negativos. Cuando el array se declara utilizando el constructor, se debe dejar un espacio
tras cada delimitador para mejorar la legibilidad:
$sampleArray = array(1, 2, 3, "ispCP");
También está permitido declarar arrays inicializados mediante el constructor. En este caso, cada
línea sucesiva debe alinearse con la superior de la siguiente manera:
$sampleArray = array(
1, 2, 3, "ispCP",
$a, $b, $c,
56.44, $d, 500
);
6.1.2.7. Llamadas a función
Las funciones deben invocarse sin espacios entre el nombre de la función, el paréntesis de
apertura y el primer parámetro. Después deben situarse comas entre cada parámetro y no
existir espacios entre el último parámetro, el último paréntesis y el punto y coma final.
<?php
$var = foo($bar, $baz, $quux);
?>
6.1.2.8. Estructuras de control
Esto incluye a las instrucciones de tipo if, for, while, switch. Las instrucciones de control deben
tener un espacio entre la palabra reservada del control y el paréntesis. De esta manera se
distinguen de las llamadas a funciones. Un ejemplo de una instrucción if es la siguiente:
<?php
if ((condition1) || (condition2)) {
action1;
} elseif ((condition3) && (condition4)) {
action2;
} else {
defaultaction;
}
?>

www.aragon.es
6.1.3. Nomenclatura
6.1.3.1. Clases
Los nombres de clases sólo pueden contener caracteres alfanuméricos. Se desaconseja el uso
de números dentro de la nomenclatura de clases.
Si se utiliza más de una palabra para el nombre de una clase, es necesario poner en mayúscula la
primera letra de cada palabra. El resto de las letras no pueden indicarse en mayúsculas.
La clase "Rcci_Genera_PDF" no está permitida

La clase "Rcci_Genera_Pdf" está permitida
6.1.3.2. Clases Abstractas
En general, las clases abstractas siguen las mismas consideraciones que las clases, pero con una
regla adicional: deben terminar con la palabra "Abstract". Este sufijo no puede ir precedido de
guión bajo.
La clase Zend_Controller_Plugin_Abstract es considerada como inválida

La clase Zend_Controller_PluginAbstract sería válida.
6.1.3.3. Interfaces
Las interfaces siguen la misma convención que las clases con la única regla adicional que deben
finalizar con la palabra "Interface". Este sufijo no puede ir precedido de guión bajo.
La interfaz Zend_Controller_Plugin_Interface es considerada inválida

La interfaz Zend_Controller_PluginInterface es considerada como válida
6.1.3.4. Nombre de ficheros
Para todos los ficheros, sólo los caracteres alfanuméricos, guiones bajos y el guión normal están
permitidos. Los espacios están estrictamente prohibidos. Todos los ficheros que contienen
código PHP terminan con la extensión ".php", con la excepción de la vista de los scripts.
6.1.3.5. Funciones y Métodos
Los nombres de las funciones sólo pueden contener caracteres alfanuméricos. Los guiones
bajos no están permitidos y el uso de los números es desaconsejable. Las funciones siempre
comienzan en minúsculas. Si una función tiene más de una palabra, cada palabra a excepción de
la primera debe de comenzar en mayúsculas. Es recomendable dar un nombre a la función que
describa su funcionalidad y su comportamiento
// Ejemplos de funciones
filtradoEntrada()
getElementoPorId()

www.aragon.es
En la programación orientada a objetos, los métodos que acceden a los objetos deben ser
siempre prefijados por "get" o "set". Cuando se usan patrones de diseño, tales como singleton
o factory, el nombre del método debería contener el nombre del patrón para facilitar la lectura del
código.
Las funciones de ámbito global están permitidas, pero se desaconseja su uso. Se recomienda que
estas funciones se encapsulen en clases estáticas.
6.1.3.6. Variables
Los nombres de las variables solo pueden contener caracteres alfanuméricos. Los guiones
bajos no están permitidos y el uso de los números es desaconsejable.
Para las variables que son declaradas con el modificador "private" o "protected", el primer carácter
debe de ser un simple guion bajo. Las variables declaradas como públicas nunca comenzarán con
guion bajo. Las variables siempre comenzarán con una letra en minúscula y seguir la convención
de mayúsculas "camelCaps".
Se recomienda que los nombres de las variables sean tan descriptivos como sea posible, para
facilitar el entendimiento del código. Los nombres de variables como "$i" y "$j" están
desaconsejados para otro contexto que no sean bucles sencillos. Si un bucle contiene más de 20
líneas de código, los nombres de las variables índices, deben tener nombres más descriptivos
6.1.3.7. Constantes
Los nombres de las constantes sólo pueden contener caracteres alfanuméricos. Si el nombre de
la constante está compuesto por varias palabras, éstas deben de ir separadas por guion bajo (_).
Se permite el uso de números pero se desaconseja su uso. Todos los caracteres de las
constantes deben ser escritos siempre en mayúsculas.
Las constantes deben ser definidas como miembros de una clase con la palabra clave "const". La
definición de constantes de ámbito global está permitida con "define" pero se desaconseja.
La constantes TEXTO_CARTA_LARGA está permitida,

mientras que la constante TEXTO_CARTALARGA no está permitida
6.1.4. Ficheros
6.1.4.1. Nomenclatura de ficheros
Para revisar los nombres de ficheros se utilizan las funciones realpath() y basename(). La
primera convierte direcciones relativas en absolutas y la segunda toma una ruta y devuelve
la parte correspondiente al nombre del fichero.
$file = $_POST[‘username’]; $file2 = basename (realpath($file)); if ($file2 != $file)

die (“$file no es un username válido”); include (“/usr/local/lib/bienvenida/$file”);

www.aragon.es
Se podría limitar las operaciones sobre ficheros a un directorio especificado y sus

subdirectorios.
include (“/alguna/ruta/lib.inc”); // permitido

include (“/otra/ruta/lib.inc”); // da error
NOTA: por securización del entorno -tal y como se refleja en el Anexo “Securización del entorno”-
está desactivada la funcionalidad de acceso a ficheros remotos (allow_url_fopen = off) y definida la
directiva open_basedir.
6.1.4.2. Subida de ficheros
Debe evitar utilizar el nombre enviado por el navegador (podría ser, por ejemplo,
/etc/passwd). Es conveniente generar un nombre único para el fichero subido.
Para limitar el tamaño de los ficheros se utiliza la directiva post_max_size de php.ini.
6.1.4.3. Bibliotecas
Debe almacenar los ficheros de biblioteca fuera de la raíz de la web para evitar que puedan
ser accedidos por su URL e indicar a PHP la ubicación de esos ficheros indicando la ruta
completa en los include() y require() o mediante la directiva include_path en php.ini
include_path = “.:/usr/local/php:/usr/local/lib/myapp”
6.1.5. Gestión de dependencias
Existen gran cantidad de librerías, frameworks y componentes de PHP que pueden ser utilizados
en los proyectos: dependencias de proyecto.
Actualmente hay dos sistemas principales de gestión de paquetes para PHP: Composer y PEAR.
El uso recomendado es el siguiente:
Composer: gestionar las dependencias de un solo proyecto.
PEAR: gestionar las dependencias de todo el sistema de PHP de la plataforma.
6.1.5.1. Composer y Packagist
Solo hay que añadir las dependencias de su proyecto a un archivo llamado composer.json,
ejecutar algunos comandos y Composer descargará automáticamente las dependencias para su
proyecto y configurará el cargador automático en cuestión de segundos.
Ya existen muchas librerías PHP compatibles con Composer y están listas para su uso. Hay una
lista de estos “paquetes” en el sitio Packagist, que es el repositorio oficial de librerías compatibles
con Composer.

www.aragon.es
A tener en cuenta:
1.- Activar la recepción de notificaciones de actualización y nuevas versiones

mediante VersionEye.
2.- Revisar las dependencias por actualizaciones de seguridad mediante Security Advisories
Checker
Más acerca de Composer
6.1.5.2. PEAR
Otra alternativa para la gestión de paquetes es PEAR. Su funcionamiento es muy similar al de

Composer. También puede utilizarse conjuntamente con Composer.
Más acerca de PEAR.
Más acerca de PEAR con Composer.
6.1.6. Verificaciones SonarQube
Se han automatizado verificaciones para garantizar la calidad software del proyecto que va a
entregar utilizando la herramienta SonarQube. Debe realizar verificaciones para subsanar los
problemas que se detecten. Existen para SonarQube plugins como pmd, checkstyles, findbugs…
Para usar estas primeras verificaciones puede descargar el perfil del proyecto SonarQube en la
intranet de AST: http://ast.aragon.es.
6.1.6.1. Crítica
No utilizar la función sleep

www.aragon.es
Esta función hace que la aplicación sea más vulnerable a los ataques DoS (denegación del
servicio).
Ejemplo de código no válido:
if (is_bad_ip($requester)) {
sleep(5); // Noncompliant
}
No hardcodear credenciales
Deben ser almacenadas fuera del código encriptadas en un fichero de configuración o en BBDD.
Ejemplo de código válido:
$uname = getEncryptedUser();
$password = getEncryptedPass();
connect($uname, $password);
No pasar parámetros por referencia
A partir de PHP 5.4.0 utilizar llamadas con parámetros por referencia causará un error fatal.
myfun($name);
Utilizar break en la sentencia switch
Si no se explicita terminar la ejecución de “case” se continúan ejecutando los casos siguientes.

En caso que no se realice intencionadamente debe finalizarse siempre con “break”.
switch ($myVariable) {
case 0: // Empty case used to specify the same behavior for a
group of cases.
case 1:
do_something();
break;
case 2: // Use of continue statement
continue;
case 3: // Case includes a jump statement (exit, return, break
&etc)
exit(0);
case 4:
echo 'Second case, which falls through';
// no break <- comment is used when fall-through is intentional in a non-
empty case body
default: // For the last case, use of break statement is optional
doSomethingElse();
}
Ubicar al final los argumentos con valor por defecto
Para evitar resultados inesperados y warnings del tipo “Missing argument 2 in call to
nombreFuncion()”.

www.aragon.es
function makeyogurt($flavour, $type = "acidophilus", ){...}
No usar exit() ni die() para el manejo de errores
En algunas ocasiones se utiliza la función die() en condicionales para realizar un control sobre los
errores. Esto puede suponer graves problemas para la aplicación: en el caso que se produzca el
error no se reportará información del mismo provocando un sensación poco agradable en el
usuario. Es más recomendable utilizar funciones como trigger_error() y en conjunto con
set_error_handler() para manejar los errores de tu aplicación.
class Foo {
public function bar($param) {
if ($param === 42) {
throw new Exception('Value 42 is not expected.');
}
}
}
6.1.6.2. Mayor
No utilizar ErrorException, RuntimeException y Exception
En su lugar crear un tipo propio que gestione la excepción o utilizar subtipos que existan en la
librería estándar de PHP.
throw new InvalidArgumentException();

// or
throw new UnexpectedValueException();
No acceder directamente a las variables globales
Realizarlo a través de un objeto o framework que permita realizar saneamiento y validaciones de

las mismas.
$name = $this->params()->fromPost('name');
Eliminar las variables locales no usadas
No devolver muchos valores en las funciones
Complica la lectura y entender la lógica de la función. El máximo se establece a 3.
Eliminar el uso de "if(true) {...}" e "if(false){...}"

www.aragon.es
Las sentencias if con condiciones que siempre son false generan bloques de código no
funcionales y las que siempre son true son redundantes. Por ello se debe evitar el uso de
sentencias if sin condiciones.
if (true) { // Noncompliant
doSomething();
}
...
if (false) { // Noncompliant
doSomethingElse();
}
doSomething();
No dejar bloques de código vacíos
Los bloques de código vacíos deben ser eliminados. Un bloque que contenga comentarios no se
considera vacío.
for ($i = 0; $i < 42; $i++){} // Empty on purpose or missing piece of code ?
Controlar el número de parámetros en una llamada
Un número excesivo de parámetros indica que pueden resolverse mediante el uso de objetos. No
es recomendable realizar llamadas que involucren a más de 7 parámetros.
No sobrecargar funciones
Se recomienda no realizar funciones con más de 150 líneas.
No sobrecargar “switch case”
En vez de añadir líneas se debe extraer a una función. El máximo de líneas permitido es 10.
Evitar comentar bloques de código
Si existen bloques de código que no se utilizan se deben eliminar en vez de comentarlos.
No variar las condiciones de parada/incremento en “for”
La condición de parada se establece en una variable local antes de que comience el bucle y no
debe modificarse en el cuerpo.
for ($i = 0; $i < 10; $i++) {

echo $i;
if(condition) {

www.aragon.es
$i = 20;
}
}
for ($i = 0; $i < 10; $i++) {

echo $i;
}
"if ... else if" debe terminar con una sentencia "else"
La última acción debe finalizar siempre con sentencia “else” y no con “else if”.
if (condition1) {
do_something();
} else if (condition2) {
do_something_else();
} else {
throw new InvalidArgumentException('message');
}
"switch" debe terminar con una sentencia "case default”
Es el mismo caso que la situación anterior.
switch ($param) {
case 0:
do_something();
break;
case 1:
do_something_else();
break;
default:
error();
break;
}
"if”, “for”, “while”, “switch" y “try” no deben ser muy anidadas
La máxima profundidad de anidamiento debe ser 4.
Eliminar los parámetros no utilizados en una función
“switch” no debe tener demasiadas sentencias “case”
El máximo permitido es 30.
La llave de apertura “{“ ha de estar al final de la línea
No usar variables predefinidas deprecadas

www.aragon.es
Utilizar las que ofrecen en la nueva versión. P.e.:
REPLACE WITH
$HTTP_SERVER_VARS $_SERVER
$HTTP_GET_VARS $_GET
$HTTP_POST_VARS $_POST
$HTTP_POST_FILES $_FILES
$HTTP_SESSION_VARS $_SESSION
$HTTP_ENV_VARS $_ENV
$HTTP_COOKIE_VARS $_COOKIE
No usar las declaraciones “constructor” de PHP4
En PHP 5 debe utilizarse el método "__construct".
En las funciones “__construct” PHP5 no usar el estilo de llamada de PHP4
class Foo extends Bar {

function __construct() {
parent::__construct();
}
}
Cumplir la nomenclatura en los nombres de clase
No utilizar la función eval()
Para asegurar que los datos usados en la construcción no han sido manipulados.
Las clases no deben ser complejas
La máxima complejidad permitida es 200.
Eliminar cuerpos de código vacíos
No utilizar el mismo nombre para las variables locales y las clases
No usar en llamadas a métodos ni mezclar con otros operadores en expresiones los

operadores de incremento (++) y decremento (--)
No utilizar variables variable
Utilizar siempre llaves en las estructuras de control
No utilizar la sentencia “goto”

www.aragon.es
Separar las sentencias en líneas diferentes
Combinar las sentencias “if” y no anidarlas
Las expresiones no deben ser complejas
El número máximo de operadores condicionales en la expresión es de 3.
Eliminar los campos “private” declarados y no utilizados
Las funciones no deben ser complejas
El máximo nivel permitido es de 20.
Cumplir la nomenclatura en las constantes
Cumplir la nomenclatura en las variables locales y funciones
Revisar los tags “FIXME” utilizados
Las clases no deben tener muchos métodos
El máximo establecido es 20.
Los ficheros no deben tener muchas líneas
Las máximas líneas permitidas son 1000.
No duplicar bloques en los fuentes
Comentar suficientemente los fuentes
La densidad requerida es de 25.0.
6.1.6.3. Menor
“switch” debe contener tres sentencias “case” mínimo
No utilizar tabuladores
No duplicar cadenas de texto
No declarar variables locales y devolverlas inmediatamente después
Colocar la llave de cierre “]” en el principio de una línea
Utilizar bucle “while” en lugar de “for”
No utilizar en expresiones de condición literales booleanos

www.aragon.es
No devolver expresiones boleanas en sentencias “if-then-else”
6.1.6.4. Info
No ubicar los comentarios al final de las líneas de código
Revisar los tags “TODO” utilizados
6.1.7. Buenas prácticas
6.1.7.1. No sobrecargar métodos
Comprobar que los métodos hacen lo que tienen que hacer y no desarrollan una excesiva
funcionalidad que provoca que su mantenimiento sea complejo. No es recomendable crear
métodos con más de 100 líneas de código.
6.1.7.2. No usar funciones dentro de bucles de conteo
El siguiente código seguro que funciona, pero el problema es que la función count() que es
ejecutada dentro de la iteración del bucle torna penaliza severamente la velocidad del proceso el
proceso.
<?php
for ($i = 0; $i < count($miArray); $i++)
{
// Código
}
?>
Si calculamos la función fuera del bucle, mejoramos la velocidad en torno a un 600% con
respecto a la función inicial.
<?php $total = count($miArray);

for ($i = 0; $i < $total; $i++)
{
// Código
}
?>
6.1.7.3. Declarar los métodos estáticos
Si es posible, hay que declarar los métodos como estáticos si van a ser tratados de esta
manera. Está probado que se reduce su tiempo de ejecución hasta cuatro veces con respecto a
los métodos que no están declarados como estáticos.

www.aragon.es
6.1.7.4. Utilizar la variable $_SERVER [ ’REQUEST_TIME’ ]
Cuando necesite calcular el tiempo actual dentro de la ejecución del algún script dentro de una
aplicación es mucho más eficiente utilizar $_SERVER [ ’REQUEST_TIME’ ] que la función time().
6.1.7.5. Utilizar foreach() en los bucles de colecciones y arrays
Cuando tenemos una estructura con un bucle destinado a la lectura de un array o una colección
está demostrado que es mucho más rápido utilizar foreach(), preferentemente a estructuras del
tipo while o for.
// Un ejemplo basado en array Hash con 100 elementos, 24 byte para claves y 10k datos
por cada entrada
foreach($aHash as $val) // Tiempo de ejecución + 100 %
while(list(,$val) = each($aHash) // Tiempo de ejecución + 579 %
6.1.7.6. Utilizar strpos() para las búsquedas de subcadenas
Para realizar la búsqueda de subcadenas dentro de cadenas de texto, la mejor manera de

realizarlo es utilizar la función strpos(), preferentemente sobre preg_match() o ereg().
<?php
if (strpos($authors, 'Chris') !== FALSE) {
echo 'Chris is an author.';
} else {
echo 'Chris is not an author.';
}
?>
6.1.7.7. Realizar preincremento de las variables
Realizar un preincremento como ++$i es más rápido que el postincremento $i++ en las variables,
así que use el preincremento cada vez que sea posible. El preincremento es casi un 10% más
rápido: debe cambiar las instrucciones para que hagan el pre-incremento, sobre todo en los
bucles críticos.
6.1.7.8. Realizar depuraciones de código
Errores en el código pueden consumir los recursos dedicados, por ello debe revisar la salida que
las páginas producen con el fin de asegurarse de que PHP no está registrando errores.
Existen funciones que aumentan la capacidad de depuración, permitiendo comprobar los scripts
sin necesidad de mostrar datos en HTML. Algunas son SitePoint, Xdebug y Scream.
6.1.7.9. Variables globales
En relación a las variables debe:

www.aragon.es
Inicializar todas las variables antes de usarlas.
Evitar la aparición de mensajes de aviso o error (en el entorno de producción).
NOTA: tal y como se refleja en el Anexo “Securización del entorno”, la directiva register_globals
tiene el valor off.
6.2. Documentación
Los bloques de documentación deben ser compatibles con phpDocumentor.
6.2.1. Ficheros
Cada fichero que contenga código PHP debe tener un bloque cabecera al comienzo del fichero
que contenga estos tags de phpDocumentor como mínimo:
/**
* Short description for file
*
* Long description for file (if any)...
*
* LICENSE: Some license information
*
* @copyright 2005 Zend Technologies
* @license http://www.zend.com/license/3_0.txt PHP License 3.0
* @version CVS: $Id:$
* @link http://dev.zend.com/package/PackageName
* @since File available since Release 1.2.0
*/
6.2.2. Clases
Cada clase debe tener un bloque que contenga estos tags de phpDocumentor como mínimo:
/**
* Short description for class
*
* Long description for class (if any)...
*
* @copyright 2005 Zend Technologies
* @license http://www.zend.com/license/3_0.txt PHP License 3.0
* @version Release: @package_version@
* @link http://dev.zend.com/package/PackageName
* @since Class available since Release 1.2.0
* @deprecated Class deprecated in Release 2.0.0
*/
6.2.3. Funciones
Cada función o método, debe tener un bloque de documentación que contenga al menos:

www.aragon.es
Una descripción de la función
Todos los argumentos
Todos los posibles valores de retorno
No es necesario el uso del tag @access ya que el nivel de acceso es conocido por las palabras
clave "public", "private", o "protected" usadas para declarar la función.
Si una función o método puede lanzar una excepción debe usarse el tag @throws:
@throws exceptionclass [description]
6.3. Bases de datos

Hasta la versión de PHP 5.1.0 la opción recomendada para conectar con BBDD era utilizar drivers
nativos (mysqli, pgsql, mssql…), actualmente la extensión PDO (Objetos de Datos de PHP) se
considera la manera más correcta y segura de acceder a cualquier BBDD.
6.3.1. Extensiones
6.3.1.1. MySQL extensión
Extensión muy antigua que ha sido sustituida por:
mysqli
pdo
mysql ha sido deprecada en versión PHP 5.5.0 y eliminada en PHP 7.0. Se recomienda la
actualización a cualquiera de esas extensiones incluso aunque no se utilice PHP 7.0 sino versiones
anteriores.
6.3.1.2. PDO extensión
PDO (PHP Data Objects) se incluye desde la versión 5.1.0 de PHP proporcionando un interfaz
común para conectar con diferentes BBDD. Además permite incluir –de forma segura- entradas
externas (p.e. IDs) en las sentencias SQL sin tener que preocuparse de ataques a la BBDD.
Más acerca de PDO.
6.3.2. Inyección SQL
Validar los valores que se han de integrar en la consulta SQL

www.aragon.es
Nunca incluir datos de usuario en la sentencia SQL
No utilizar mysql_real_escape_string
Utilizar sentencias preparadas. En caso que no se pudiera debería utilizar el constructor de

sentencias del framework o utilizar paquetes proporcionados por Composer-Packagist.
6.4. Caché
Para la mejora del rendimiento se recomienda el uso de diferentes utilidades de caché que
mejoren la carga de las páginas del sitio.
6.4.1. Opcode cache
Previene recompilaciones almacenando códigos opcode en memoria y reutilizándolos. Algunas

cachés opcode disponibles son:
OPcache (desde PHP 5.5)
APC (PHP 5.4 y anteriores)
XCache
Zend Optimizer+ (parte del paquete Zend Server)
WinCache (extensión para MS Windows Server)
List of PHP accelerators on Wikipedia
6.4.2. Caché de objetos
Importante cuando hay que cachear objetos individuales para almacenarlos en memoria y obtener
un acceso rápido a ellos. Las soluciones más populares son: APCu, memcached, XCache y
WinCache.
Las más utilizadas son APCu y memcached. APCu es mejor para el cache de objetos, su pega es
que se asocia al servidor en que está instalado. Memcached se instala como servicio separado y
puede accederse a través de la red, es más indicado para instalaciones de varios servidores.
Se determina pues el uso de Memcached en sistemas distribuidos y en caso contrario APCu.

www.aragon.es
6.5. Seguridad
6.5.1. Seguridad en aplicaciones web
Debe tomar las precauciones necesarias para mejorar la seguridad de los proyectos.
La comunidad del The Open Web Application Security Project (OWASP) ha compilado una lista
completa de problemas de seguridad conocidos y los métodos a seguir para protegerse contra
ellos. Esta guía es lectura obligada para cualquier desarrollador.
Leer la Guía de seguridad de OWASP (Disponible solo en inglés)
6.5.2. Password Hashing

Al desarrollar una aplicación PHP que realice una conexión de usuario debe de realizar hash de
las contraseñas antes de almacenarlas, ya que si no están hasheadas y accede a la base de
datos un tercero no autorizado, todas las cuentas de usuario están comprometidas.
Para ello se ha de utilizar password_hash(). Actualmente utiliza el algoritmo BCrypt, en un futuro

soportará algoritmos adicionales.
6.5.3. Filtrado de Datos
Siempre debe sanear y verificar los datos de entrada de la aplicación PHP antes de usarlos en el
código. Las funciones filter_var() y filter_input() proporcionan limpieza de los datos y verifican la
validez del formato del texto (por ejemplo, las direcciones de correo electrónico).
Los datos de entrada exteriores pueden contener cualquier cosa: datos provenientes de
formularios en $_GET y $_POST, algunos valores provenientes del $_SERVER, el cuerpo de la
solicitud HTTP vía la función fopen('php://input', 'r'). Han de ser filtrados de diferente manera
dependiendo de su propósito.
Datos sin filtrar a la salida de HTML: se corre el riesgo de ejecutar código sin verificar de
HTML o JavaScript en el sitio: Cross-Site Scripting (XSS). Para prevenir estos ataques hay
que sanear todas las etiquetas de HTML en los datos de entrada al remover etiquetas o
convirtiéndolas en entidades de HTML. Se puede utilizar strip_tags(), htmlentities() o
htmlspecialchars().
Pasar opciones que van a ser ejecutadas en la línea de comando: es extremadamente

peligroso. Se puede usar la función escapeshellarg -que viene incluida en PHP- para
sanear los argumentos de ejecución de un comando.
Aceptar la entrada de datos para determinar qué archivo necesita cargar del sistema
de archivos: debe quitar los caracteres “/”, “../”, bytes nulos y otros de la ruta de archivo
para que no permita cargar archivos escondidos, no públicos, o sensitivos.
Más sobre los filtros de saneamiento

www.aragon.es
6.5.4. Gestión de la sesión
6.5.4.1. Medidas contra la predicción de sesión
Aleatorización y longitud suficiente del identificador de sesión: la configuración por

defecto de aleatorización del identificador de sesión es suficientemente buena, pero se
pueden añadir fuentes de datos para la generación del identificador mediante
session.entropy_file y session.entropy_length para, por ejemplo, utilizar el API de Windows
o el archivo /dev/random en sistemas Unix
6.5.4.2. Medidas contra la captura del identificador a través de ataques XSS
Las cookies sólo son accesibles a través del protocolo HTTP: está activada la opción
session.cookie_httponly.
Está deshabilitado el método TRACE.
6.5.4.3. Medidas contra la fijación de sesión
Renovar el identificador al autenticarse el usuario o asignarlo únicamente después de la

autenticación: utilizar la función session_regenerate_id, siempre con el parámetro
"$delete_old_session = true" para que el identificador de la sesión anterior no sea utilizable.
Permitir únicamente el identificador en cookies: esta restricción, activa por defecto, se

controla mediante la variable session.use_only_cookies.
Asociar el identificador a información del usuario única como su dirección IP: la

dirección IP, que se puede obtener de la variable $_SERVER['REMOTE_ADDR'], puede
almacenarse en los datos de sesión, a través de $_SESSION, y simplemente en cada
nueva petición comprobar que no ha cambiado. Esta medida no tiene por qué limitarse a la
dirección IP, se puede establecer un perfil más detallado a través de acciones comunes,
patrones de navegación, localización, etc.
6.5.4.4. Medidas contra el eavesdropping
Utilizar el protocolo HTTPS.
Utilizar la opción secure en las cookies de sesión ya que está activada la opción
session.cookie_secure.
6.5.4.5. Medidas contra los errores en el cierre de sesión
Establecer un timeout de sesión. Se puede utilizar un código similar al siguiente para

controlar este timeout:
if (!isset($_SESSION['timeout_idle'])) {

www.aragon.es
$_SESSION['timeout_idle'] = time() +
ini_get('session.gc_maxlifetime');
} else {
if ($_SESSION['timeout_idle'] < time()) {
//destroy session
} else {
$_SESSION['timeout_idle'] = time() +
ini_get('session.gc_maxlifetime');
}
}
Se puede delegar esta medida de seguridad en el mecanismo de eliminación de archivos

de sesión que no han sido accedidos en el tiempo definido por session.gc_maxlifetime, pero
entonces habrá que ajustar su ejecución para que no sea aleatoria y para que dependa de
una tarea programada.
Establecer un tiempo máximo de validez de sesión: este timeout puede ser establecido
mediante un código similar al anterior, utilizando el parámetro session.cookie_lifetime, etc.
Utilizar cookies no persistentes: el tiempo de validez de la cookie se controla mediante el

parámetro session.cookie_lifetime que por defecto es 0, lo que significa que no es
persistente. Por otro lado, por defecto las cookies están restringidas al dominio y directorio
raíz del servidor web (opciones controladas mediante session.cookie_domain y
session.cookie_path).
Invalidar y no reutilizar los identificadores de sesión: cuando se destruye la sesión,

mediante session.destroy, se elimina el archivo de sesión, por lo que cuando el usuario
acceda de nuevo el servidor web no reconocerá la sesión. Otra cosa a tener en cuenta es
invocar session_regenerate_id siempre incluyendo el parámetro "$delete_old_session =
true" para inutilizar el identificador anterior.
6.5.4.6. Medidas ante aspectos propios de la implementación de la gestión de sesiones de

PHP
Restringir el acceso al directorio session.save_path donde se guardan los archivos de

sesión sin encriptar. En la instalación por defecto, sólo tiene acceso a ese directorio el
usuario bajo el que se ejecuta el servidor web. Los usuarios no deben ni poder listar los
archivos ya que su nombre contiene el identificador de sesión.
6.5.5. Validación
La validación asegura que lo que contiene la entrada de datos es lo que se espera. Por
ejemplo, se debe validar una dirección de correo electrónico, un número telefónico, o la
edad de un usuario al procesar una solicitud de registro.
Más sobre los filtros de validación
6.5.6. Archivos de Configuración
Se han de cumplir –al menos- las buenas prácticas siguientes:

www.aragon.es
Almacenar los archivos de configuración donde no se pueda acceder a ellos

directamente por medio del sistema de archivos.
Si no hay otra alternativa más que almacenar los archivos de configuración en la raíz de
documentos de su aplicación, se debe adjuntar la extensión .php al nombre de los
archivos. De esta manera, aún si alguien accede a ellos directamente, la información no
será impresa en forma de texto a la pantalla.
La información en los archivos de configuración debe ser protegida ya sea por medio
de codificación o con los permisos de grupo/usuario pertinentes en el sistema de archivos.
6.5.7. Informe de Errores
Se recomienda aplicar los siguientes valores en el fichero php.ini en función del entorno:
Desarrollo
display_errors = On
display_startup_errors = On
error_reporting = -1 (1)
log_errors = On
(1) El valor -1 mostrará cualquier error independientemente que en versiones posteriores de PHP se añadan nuevas constantes.
Producción
display_errors = Off
display_startup_errors = Off
error_reporting = E_ALL
log_errors = On

www.aragon.es
ANEXO 1: configuración PHP

A continuación se muestra la configuración de PHP en producción.
PHP Version 5.4.16
PHP Version => 5.4.16
System => Linux mov-lamp2016-01 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 9 10:09:10

EDT 2016 x86_64
Build Date => Apr 4 2016 07:13:12
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc
Loaded Configuration File => /etc/php.ini
Scan this dir for additional .ini files => /etc/php.d
Additional .ini files parsed => /etc/php.d/curl.ini,
/etc/php.d/fileinfo.ini,
/etc/php.d/json.ini,
/etc/php.d/phar.ini,
/etc/php.d/zip.ini
PHP API => 20100412

PHP Extension => 20100525
Zend Extension => 220100525
Zend Extension Build => API220100525,NTS
PHP Extension Build => API20100525,NTS
Debug Build => no
Thread Safety => disabled
Zend Signal Handling => disabled
Zend Memory Manager => enabled
Zend Multibyte Support => disabled
IPv6 Support => enabled
DTrace Support => disabled
Registered PHP Streams => https, ftps, compress.zlib, compress.bzip2, php, file,
glob, data, http, ftp, phar, zip
Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
Registered Stream Filters => zlib.*, bzip2.*, convert.iconv.*, string.rot13,
string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk
Configuration
bz2
BZip2 Support => Enabled

Stream Wrapper support => compress.bzip2://
Stream Filter support => bzip2.decompress, bzip2.compress
BZip2 Version => 1.0.6, 6-Sept-2010
calendar
Calendar support => enabled
Core
Directive => Local Value => Master Value

allow_url_fopen => Off => Off
allow_url_include => Off => Off

www.aragon.es
always_populate_raw_post_data => Off => Off

arg_separator.input => & => &
arg_separator.output => & => &
asp_tags => Off => Off
auto_append_file => no value => no value
auto_globals_jit => On => On
auto_prepend_file => no value => no value
browscap => no value => no value
default_charset => no value => no value
default_mimetype => text/html => text/html
disable_classes => no value => no value
disable_functions =>
symlink,system,shell_exec,exec,proc_get_status,proc_nice,proc_terminate,define_syslog
_variables,syslog,openlog,closelog,escapeshellcmd,passthru,ocinumcols,ini_alter,leak,
listen,chgrp,apache_note,apache_setenv,debugger_on,debugger_off,ftp_exec,dl,dll,ftp,m
yshellexec,proc_open,socket_bind,proc_close,popen,show_source,curl_exec,curl_multi_ex
ec,parse_ini_file =>
symlink,system,shell_exec,exec,proc_get_status,proc_nice,proc_terminate,define_syslog
_variables,syslog,openlog,closelog,escapeshellcmd,passthru,ocinumcols,ini_alter,leak,
listen,chgrp,apache_note,apache_setenv,debugger_on,debugger_off,ftp_exec,dl,dll,ftp,m
yshellexec,proc_open,socket_bind,proc_close,popen,show_source,curl_exec,curl_multi_ex
ec,parse_ini_file
display_errors => Off => Off
display_startup_errors => Off => Off
doc_root => no value => no value
docref_ext => no value => no value
docref_root => no value => no value
enable_dl => Off => Off
enable_post_data_reading => On => On
error_append_string => no value => no value
error_log => no value => no value
error_prepend_string => no value => no value
error_reporting => 22527 => 22527
exit_on_timeout => Off => Off
expose_php => Off => Off
extension_dir => /usr/lib64/php/modules => /usr/lib64/php/modules
file_uploads => On => On
highlight.comment => #FF8000 => #FF8000
highlight.default => #0000BB => #0000BB
highlight.html => #000000 => #000000
highlight.keyword => #007700 => #007700
highlight.string => #DD0000 => #DD0000
html_errors => Off => Off
ignore_repeated_errors => Off => Off
ignore_repeated_source => Off => Off
ignore_user_abort => Off => Off
implicit_flush => On => On
include_path => .:/usr/share/pear:/usr/share/php => .:/usr/share/pear:/usr/share/php
log_errors => On => On
log_errors_max_len => 1024 => 1024
mail.add_x_header => On => On
mail.force_extra_parameters => no value => no value
mail.log => no value => no value
max_execution_time => 0 => 0
max_file_uploads => 20 => 20
max_input_nesting_level => 64 => 64
max_input_time => -1 => -1
max_input_vars => 1000 => 1000
memory_limit => 128M => 128M
open_basedir => /var/www/sites => /var/www/sites
output_buffering => 0 => 0

www.aragon.es
output_handler => no value => no value

post_max_size => 8M => 8M
precision => 14 => 14
realpath_cache_size => 16K => 16K
realpath_cache_ttl => 120 => 120
register_argc_argv => On => On
report_memleaks => On => On
report_zend_debug => Off => Off
request_order => GP => GP
sendmail_from => no value => no value
sendmail_path => /usr/sbin/sendmail -t -i => /usr/sbin/sendmail -t -i
serialize_precision => 17 => 17
short_open_tag => Off => Off
SMTP => localhost => localhost
smtp_port => 25 => 25
sql.safe_mode => Off => Off
track_errors => Off => Off
unserialize_callback_func => no value => no value
upload_max_filesize => 2M => 2M
upload_tmp_dir => /tmp => /tmp
user_dir => no value => no value
user_ini.cache_ttl => 300 => 300
user_ini.filename => .user.ini => .user.ini
variables_order => GPCS => GPCS
xmlrpc_error_number => 0 => 0
xmlrpc_errors => Off => Off
zend.detect_unicode => On => On
zend.enable_gc => On => On
zend.multibyte => Off => Off
zend.script_encoding => no value => no value
ctype
ctype functions: enabled
curl
cURL support => enabled

cURL Information => 7.29.0
Age => 3
Features
AsynchDNS => Yes
Debug => No
GSS-Negotiate => Yes
IDN => Yes
IPv6 => Yes
Largefile => Yes
NTLM => Yes
SPNEGO => No
SSL => Yes
SSPI => No
krb4 => No
libz => Yes
CharConv => No
Protocols => dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, ldaps,
pop3, pop3s, rtsp, scp, sftp, smtp, smtps, telnet, tftp
Host => x86_64-redhat-linux-gnu
SSL Version => NSS/3.16.2.3 Basic ECC
ZLib Version => 1.2.7
libSSH Version => libssh2/1.4.3
date
date/time support => enabled

www.aragon.es
"Olson" Timezone Database Version => 0.system

Timezone Database => internal
Default timezone => UTC

date.default_latitude => 31.7667 => 31.7667
date.default_longitude => 35.2333 => 35.2333
date.sunrise_zenith => 90.583333 => 90.583333
date.sunset_zenith => 90.583333 => 90.583333
date.timezone => no value => no value
ereg
Regex Library: Bundled library enabled
exif
EXIF Support => enabled

EXIF Version => 1.4 $Id$
Supported EXIF Version => 0220
Supported filetypes => JPEG,TIFF

exif.decode_jis_intel => JIS => JIS
exif.decode_jis_motorola => JIS => JIS
exif.decode_unicode_intel => UCS-2LE => UCS-2LE
exif.decode_unicode_motorola => UCS-2BE => UCS-2BE
exif.encode_jis => no value => no value
exif.encode_unicode => ISO-8859-15 => ISO-8859-15
fileinfo
fileinfo support: enabled

version: 1.0.5
filter
Input Validation and Filtering: enabled

Revision: $Id: 2aa8dd57d9c0c655cd45e6e5872bb95fa5ad76cf $

filter.default => unsafe_raw => unsafe_raw
filter.default_flags => no value => no value
ftp
FTP support: enabled
gettext
GetText Support: enabled
gmp
gmp support: enabled

GMP version: 6.0.0
hash

www.aragon.es
hash support => enabled

Hashing Engines => md2 md4 md5 sha1 sha224 sha256 sha384 sha512 ripemd128 ripemd160
ripemd256 ripemd320 whirlpool tiger128,3 tiger160,3 tiger192,3 tiger128,4 tiger160,4
tiger192,4 snefru snefru256 gost adler32 crc32 crc32b fnv132 fnv164 joaat haval128,3
haval160,3 haval192,3 haval224,3 haval256,3 haval128,4 haval160,4 haval192,4
haval224,4 haval256,4 haval128,5 haval160,5 haval192,5 haval224,5 haval256,5
iconv
iconv support => enabled

iconv implementation => glibc
iconv library version => 2.17

iconv.input_encoding => ISO-8859-1 => ISO-8859-1
iconv.internal_encoding => ISO-8859-1 => ISO-8859-1
iconv.output_encoding => ISO-8859-1 => ISO-8859-1
json
json support: enabled

json version: 1.2.1
libxml
libXML support: active

libXML Compiled Version: 2.9.1
libXML Loaded Version: 20901
libXML streams: enabled
mhash
MHASH support: Enabled

MHASH API Version: Emulated Support
openssl
OpenSSL support: enabled

OpenSSL Library Version: OpenSSL 1.0.1e-fips 11 Feb 2013
OpenSSL Header Version: OpenSSL 1.0.1e-fips 11 Feb 2013
pcntl
pcntl support => enabled
pcre
PCRE (Perl Compatible Regular Expressions) Support: enabled

PCRE Library Version: 8.32 2012-11-30

pcre.backtrack_limit => 1000000 => 1000000
pcre.recursion_limit => 100000 => 100000
Phar
Phar: PHP Archive support enabled

Phar EXT version: 2.0.1
Phar API version: 1.1.1

www.aragon.es
SVN revision => $Id: c5042cc34acebcc0926625b57dff03deebbe6472 $

Phar-based phar archives => enabled
Tar-based phar archives => enabled
ZIP-based phar archives => enabled
gzip compression => enabled
bzip2 compression => enabled
Native OpenSSL support => enabled

phar.cache_list => no value => no value
phar.readonly => On => On
phar.require_hash => On => On
readline
Readline Support => enabled

Readline library => EditLine wrapper

cli.pager => no value => no value
cli.prompt => \b \> => \b \>
Reflection
Reflection: enabled
Version: $Id: 6c4d8062369898a397e4b128348042f5c01b4427 $
session
Session Support: enabled

Registered save handlers: files user
Registered serializer handlers: php php_binary

session.auto_start => On => On
session.cache_expire => 180 => 180
session.cache_limiter => nocache => nocache
session.cookie_domain => no value => no value
session.cookie_httponly => On => On
session.cookie_lifetime => 0 => 0
session.cookie_path => / => /
session.cookie_secure => On => On
session.entropy_file => /dev/urandom => /dev/urandom
session.entropy_length => 32 => 32
session.gc_divisor => 1000 => 1000
session.gc_maxlifetime => 1440 => 1440
session.gc_probability => 1 => 1
session.hash_bits_per_character => 5 => 5
session.hash_function => 0 => 0
session.name => GAPHPSESSID => GAPHPSESSID
session.referer_check => no value => no value
session.save_handler => files => files
session.save_path => /tmp => /tmp
session.serialize_handler => php => php
session.upload_progress.cleanup => On => On
session.upload_progress.enabled => On => On
session.upload_progress.freq => 1% => 1%
session.upload_progress.min_freq => 1 => 1
session.upload_progress.name => PHP_SESSION_UPLOAD_PROGRESS =>
PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix => upload_progress_ => upload_progress_
session.use_cookies => On => On
session.use_only_cookies => On => On

www.aragon.es
session.use_trans_sid => 0 => 0
shmop
shmop support: enabled
SimpleXML
Simplexml support: enabled

Revision: $Id: 692516840b2d7d6e7aedb0bedded1f53b764a99f $
Schema support: enabled
sockets
Sockets Support: enabled
SPL
SPL support => enabled

Interfaces => Countable, OuterIterator, RecursiveIterator, SeekableIterator,
SplObserver, SplSubject
Classes => AppendIterator, ArrayIterator, ArrayObject, BadFunctionCallException,
BadMethodCallException, CachingIterator, CallbackFilterIterator, DirectoryIterator,
DomainException, EmptyIterator, FilesystemIterator, FilterIterator, GlobIterator,
InfiniteIterator, InvalidArgumentException, IteratorIterator, LengthException,
LimitIterator, LogicException, MultipleIterator, NoRewindIterator,
OutOfBoundsException, OutOfRangeException, OverflowException, ParentIterator,
RangeException, RecursiveArrayIterator, RecursiveCachingIterator,
RecursiveCallbackFilterIterator, RecursiveDirectoryIterator, RecursiveFilterIterator,
RecursiveIteratorIterator, RecursiveRegexIterator, RecursiveTreeIterator,
RegexIterator, RuntimeException, SplDoublyLinkedList, SplFileInfo, SplFileObject,
SplFixedArray, SplHeap, SplMinHeap, SplMaxHeap, SplObjectStorage, SplPriorityQueue,
SplQueue, SplStack, SplTempFileObject, UnderflowException, UnexpectedValueException
standard
Dynamic Library Support: enabled

Path to sendmail: /usr/sbin/sendmail -t –i

assert.active => 1 => 1
assert.bail => 0 => 0
assert.callback => no value => no value
assert.quiet_eval => 0 => 0
assert.warning => 1 => 1
auto_detect_line_endings => 0 => 0
default_socket_timeout => 60 => 60
from => no value => no value
url_rewriter.tags => a=href,area=href,frame=src,input=src,form=fakeentry =>
a=href,area=href,frame=src,input=src,form=fakeentry
user_agent => no value => no value
tokenizer
Tokenizer Support: enabled
xml
XML Support: active

XML Namespace Support: active

www.aragon.es
libxml2 Version: 2.9.1
zip
Zip: enabled
Extension Version: $Id: 0c033d4e4613d577409950ed7bf8da4b68286d15 $
Zip version: 1.11.0
Compiled against libzip version: 0.10.1
zlib
ZLib Support: enabled

Stream Wrapper: compress.zlib://
Stream Filter: zlib.inflate, zlib.deflate
Compiled Version: 1.2.7
Linked Version: 1.2.7

zlib.output_compression => Off => Off
zlib.output_compression_level => -1 => -1
zlib.output_handler => no value => no value
Environment
Variable => Value

MANPATH => :/var/cfengine/share/man
XDG_SESSION_ID => 51749
HOSTNAME => mov-lamp2016-01
SHELL => /bin/bash
TERM => xterm
HISTSIZE => 1000
USER => root
LS_COLORS =>
rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40
;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:
*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*
.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*
.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;3
1:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:
*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*
.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.
gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.x
pm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.
pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*
.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.
wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.f
lv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=
01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=0
1;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01
;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
MAIL => /var/spool/mail/root
PATH =>
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/var/cfengine/bin:/root/
bin
PWD => /var/www/sites
LANG => es_ES.UTF-8
HISTCONTROL => ignoredups
SHLVL => 1
HOME => /root
LOGNAME => root
LESSOPEN => ||/usr/bin/lesspipe.sh %s
OLDPWD => /var/www/sites
_ => /bin/php

www.aragon.es
PHP Variables
Variable => Value

_SERVER["MANPATH"] => :/var/cfengine/share/man
_SERVER["XDG_SESSION_ID"] => 51749
_SERVER["HOSTNAME"] => mov-lamp2016-01
_SERVER["SHELL"] => /bin/bash
_SERVER["TERM"] => xterm
_SERVER["HISTSIZE"] => 1000
_SERVER["USER"] => root
_SERVER["LS_COLORS"] =>
rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40
;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:
*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*
.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*
.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;3
1:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:
*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*
.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.
gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.x
pm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.
pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*
.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.
wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.f
lv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=
01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=0
1;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01
;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
_SERVER["MAIL"] => /var/spool/mail/root
_SERVER["PATH"] =>
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/var/cfengine/bin:/root/
bin
_SERVER["PWD"] => /var/www/sites
_SERVER["LANG"] => es_ES.UTF-8
_SERVER["HISTCONTROL"] => ignoredups
_SERVER["SHLVL"] => 1
_SERVER["HOME"] => /root
_SERVER["LOGNAME"] => root
_SERVER["LESSOPEN"] => ||/usr/bin/lesspipe.sh %s
_SERVER["OLDPWD"] => /var/www/sites
_SERVER["_"] => /bin/php
_SERVER["PHP_SELF"] => phpinfo.php
_SERVER["SCRIPT_NAME"] => phpinfo.php
_SERVER["SCRIPT_FILENAME"] => phpinfo.php
_SERVER["PATH_TRANSLATED"] => phpinfo.php
_SERVER["DOCUMENT_ROOT"] =>
_SERVER["REQUEST_TIME_FLOAT"] => 1472038560.2836
_SERVER["REQUEST_TIME"] => 1472038560
_SERVER["argv"] => Array
(
[0] => phpinfo.php
)
_SERVER["argc"] => 1

www.aragon.es
ANEXO 2: Securización del entorno

Funciones que no se deben utilizar
Está prohibido el uso de las siguientes funcionalidades:
phpinfo,symlink,system,shell_exec,exec,proc_get_status,proc_nice,proc_terminate,defin
e_syslog_variables,syslog,openlog,closelog,escapeshellcmd,passthru,ocinumcols,ini_alt
er,leak,listen,chgrp,apache_note,apache_setenv,debugger_on,debugger_off,ftp_exec,dl,d
ll,ftp,myshellexec,proc_open,socket_bind,proc_close,popen,show_source,curl_exec,curl_
multi_exec,parse_ini_file
Uso de PHP open_basedir
Esta directiva limita los archivos que pueden ser abiertos por PHP al árbol de directorios
especificado. Se han habilitado las siguientes opciones:
open_basedir = /var/www/sites/
upload_tmp_dir = /tmp
Deshabilitar register_globals
register_globals = Off
Deshabilitar allow_url_fopen
De este modo, no se pueden ejecutar scripts de una URL remota.
allow_url_fopen = Off
Versión de PHP
Ocultar versión de PHP.
expose_php = Off
Deshabilitar el método TRACE
TraceEnable Off
Activar session.autostart
Para iniciar sesión automáticamente al comenzar la petición.
session.auto_start = 1
Activar session.cookie_httponly
Para que las cookies sólo estén accesibles a través del protocolo http. Esto implica que
JavaScript no tiene acceso a las cookies de sesión
session.cookie_httponly = 1

www.aragon.es
Activar session.cookie_secure
Implica utilizar la opción secure en las cookies de sesión.
session.cookie_secure = 1
Cambiar el valor de session.name
_session.name = GAPHPSESSID

www.aragon.es
ANEXO 3: Convenio de Nomenclatura de Objetos de BBDD

Objetivo
El presente documento define un convenio para nominar objetos de base de datos para:
Facilitar el diseño de base de datos reduciendo el tiempo invertido en la elección

de nombres de objetos.
Evitar conflictos entre nombres de objetos de distintas aplicaciones.
Facilitar las tareas de administración.
Convenio de Nombres
Reglas.
El presente convenio sigue unas reglas fáciles de explicar y de aplicar:
Todo objeto debe ir precedido del prefijo apl_, donde apl debe sustituirse por el
código de la aplicación a la que pertenece el objeto. Esta regla evita los conflictos
entre nombres de objetos de aplicaciones distintas.
Todo objeto debe incorporar en el nombre el tipo del objeto (p.e. i para índices, pk
para primary keys, etc.). Como excepción a esta regla están las tablas, por ser el
objeto principal de la base de datos. Esta regla evita dedicar tiempo en pensar
nombres distintos para objetos de distinto tipo dentro de la misma aplicación.
Todo objeto debe terminar con una cadena de caracteres que debe definirse
libremente para distinguir los objetos del mismo tipo y aplicación.
Todo objeto que depende jerárquicamente de otro debe ir precedido del nombre
del objeto del depende (p.e. índices sobre tablas. Esta regla da una visión de la
jerarquía de objetos a nivel de nombres y proporciona un método rápido de nombrar
objetos que no son utilizados en sentencias DML.
Convenio de estilos.
La letra cursiva se utiliza para definir cadenas que deben ser sustituidas por
literales definidos previamente.
La letra negrita se utiliza para definir cadenas fijas que deben escribirse
literalmente.
Los caracteres de subrayado son fijos y deben escribirse literalmente.
La cadena ‘id’ representa cualquier cadena de caracteres válidos a definir

libremente.

www.aragon.es
Longitud de nombres.
La longitud total de un nombre de objeto no puede exceder el límite MariaDB Este límite
debe reducirse para el caso de las tablas, ya que el nombre de estas sirve de base para la
definición de otros nombres de objetos dependientes.
Tipo de Objeto Nombre Comentario

Base de Datos apl_bd # DB
Tabla apl_id # Table
Vista apl_v_id # View
Dependencias sobre Tablas
Clave Primaria tabla_pk # Primary Key
Clave Ajena tabla_fk_id # Foreign Key
Índice tabla_ix_id # Index
Convenio de Nombres
Ejemplos: OEP – Oferta de Empleo Público
Tablas: OEP_SOLICITANTES OEP_CONVOCATORIAS
Vistas: OEP_V_ADMITIDOS
Clave Primaria: OEP_SOLICITANTES_PK
Clave Foránea: OEP_SOLICITANTES_FK_CONVOCAT
Índices: OEP_SOLICITANTES_IX_DNI
OEP_SOLICITANTES_IX_APELLIDOS

www.aragon.es

Entorno LAMP

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Entorno LAMP

Cargado por

Copyright:

Formatos disponibles

Entorno LAMP 2016 del

Clasificación: Uso Público

Clasificación: Uso Público

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

4. ESPECIFICACIONES DEL ENTORNO ............................................................................................ 12

5. ESPECIFICACIONES DE DESARROLLO ....................................................................................... 15

6. OBLIGACIONES Y RECOMENDACIONES ..................................................................................... 19

Ref.: AST-ESPEC-EspecificacionesTecnicasLAMP2016.doc Entidad Pública Aragonesa de Servicios Telemáticos

Clasificación: Uso Público

6.1.2.2. Longitud de la línea ............................................................................................................. 20

Ref.: AST-ESPEC-EspecificacionesTecnicasLAMP2016.doc Entidad Pública Aragonesa de Servicios Telemáticos

Clasificación: Uso Público

6.3.1.2. PDO extensión .................................................................................................................... 35

ANEXO 1: CONFIGURACIÓN PHP...................................................................................................... 41

ANEXO 2: SECURIZACIÓN DEL ENTORNO ...................................................................................... 50

ANEXO 3: CONVENIO DE NOMENCLATURA DE OBJETOS DE BBDD .......................................... 52

Ref.: AST-ESPEC-EspecificacionesTecnicasLAMP2016.doc Entidad Pública Aragonesa de Servicios Telemáticos

Clasificación: Uso Público

Con el objetivo de facilitar la labor de desarrollo, integración y despliegue, el documento divide el

Parte IV: Especificaciones de desarrollo. Directrices que se deben seguir en el

Parte V: Obligaciones y recomendaciones. Recomendaciones y fundamentos para la

Ref.: AST-ESPEC-EspecificacionesTecnicasLAMP2016.doc Entidad Pública Aragonesa de Servicios Telemáticos

Clasificación: Uso Público

2. Arquitectura de plataforma tecnológica

1. Integración: entorno para realizar el primer despliegue de la aplicación, además de

2. Preproducción: entorno idéntico al de producción que facilitará la realización de las

3. Producción: entorno final.

El escenario que detallaremos a continuación define la estructura del entorno de producción,

Diagrama arquitectura LAMP (entorno de producción)

Ref.: AST-ESPEC-EspecificacionesTecnicasLAMP2016.doc Entidad Pública Aragonesa de Servicios Telemáticos

Clasificación: Uso Público

La nomenclatura de los servidores sigue estos criterios:

CAPA ENTORNO TIPO MÁQUINA

m-media e – preproducción l – virtual ldom

b-back i – integración v-virtual vmware

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

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

Ref.: AST-ESPEC-EspecificacionesTecnicasLAMP2016.doc Entidad Pública Aragonesa de Servicios Telemáticos

Clasificación: Uso Público

3.1. Directorios generales comunes a todos los tipos de proyecto

Los directorios que aparecen siempre en los proyectos son:

docs/ Contiene toda la documentación relativa a un proyecto

src/ Dentro de este directorio se incluyen dos subdirectorios:

• “php” donde ubicamos los ficheros fuente

NOTA: es imprescindible la entrega de un manual de instalación adecuado a la versión de la

3.1.1. Directorio docs/

Contiene toda la documentación relacionada con el proyecto: documentación técnica, manuales

3.1.2. Directorio src/

Ref.: AST-ESPEC-EspecificacionesTecnicasLAMP2016.doc Entidad Pública Aragonesa de Servicios Telemáticos

Clasificación: Uso Público

3.1.2.1. Directorio php/

3.1.2.2. Directorio conf/

Dentro de este directorio se distribuirán todos los ficheros susceptibles de parametrización de

3.1.3. Directorio setup/

3.1.3.1. Manual de instalación

Debe incluir obligatoriamente:

Descripción de la aplicación y pasos para su instalación en cada entorno.

Si es necesario que la aplicación se ejecute bajo http o https.

Instrucciones de creación de directorios en el servidor, como por ejemplo, directorios

Explicación de los ficheros de configuración distribuidos bajo el directorio src/conf/ y

Ref.: AST-ESPEC-EspecificacionesTecnicasLAMP2016.doc Entidad Pública Aragonesa de Servicios Telemáticos

Clasificación: Uso Público

en los entornos del Gobierno de Aragón. También se indicará la ubicación de los

Creación de alias o directorios virtuales en el servidor web, en caso de ser necesario.