Archivo de febrero, 2011

Beyond Black Mesa

0

Corto basado en el juego Half Life 2. Si os gustó el juego esto no os lo podéis perder:

Symfony: La vista (IV), mecanismo de escape

0

Este capítulo del libro me está resultando de lo más pesado, principalmente porque no hay mucho con lo que practicar, ya que la mayoría de la información es teoría basada en donde ubicar cada cosa en cada caso. Aunque las posibilidades que ofrece Symfony a medida que te adentras en él, son enormes.

Para acabar con la vista solo queda ver el mecanismo de escape que utiliza Symfony. Empezemos:

Este apartado del libro comienza así:

Cuando se insertan datos generados dinámicamente en una plantilla, se debe asegurar la integridad de los datos. Por ejemplo, si se utilizan datos obtenidos mediante formularios que pueden rellenar usuarios anónimos, existe un gran riesgo de que los contenidos puedan incluir scripts y otros elementos maliciosos que se encargan de realizar ataques de tipo XSS (cross-site scripting). Por tanto, se debe aplicar un mecanismo de escape a todos los datos mostrados, de forma que ninguna etiqueta HTML pueda ser peligrosa.

ACTIVANDO EL MECANISMO DE ESCAPE

Fácil. El mecanismo de escape se activa en el archivo config/settings.yml de la aplicación utilizando para ello dos parámentros:

  • scaping_strategy: Define la forma en la que las variables están disponibles en la vista.
  • scaping_method: Indica la función que se aplica a los datos.

all:
.settings:
escaping_strategy: both
escaping_method: ESC_ENTITIES

Esto de aquí arriba es lo único que tendrás que escribir para activar el mecanismo de escape. Ahora mismo, nuestra aplicación estaría utilizando el método htmlentities() de PHP para escapar los caracteres de html. Más adelante veremos más valores que pueden tener estos parámentros.

Por ejemplo, si tenemos en nuestra acción esta variable:

$this->prueba = ‘<script>alert(document.cookie)</script>’;

Al tener el mecanismo de escape activado, al mostrarla en la plantilla nos dará el siguiente resultado:

echo $prueba;
=> &gt;&lt;script&gt;alert(document.cookie)&lt;/script&gt;

Si se activa el mecanismo de escape, desde cualquier plantilla se puede acceder a una nueva variable llamada $sf_data. Se trata de un objeto contenedor que hace referencia a todas las variables que se han modificado mediante el sistema de escape. De esta forma, también es posible mostrar el contenido de la variable prueba de la siguiente manera:

echo $sf_data->get(‘prueba’);
=> &gt;&lt;script&gt;alert(document.cookie)&lt;/script&gt;

Con esta clase también podemos acceder a los datos de la variable en crudo, es decir, antes de que sus caracteres fuesen escapados:

echo $sf_data->getRaw(‘prueba’);
=> <script>alert(document.cookie)</script>

OPCIONES PARA scaping_strategy

  • backward compatible mode (o modo retrocompatible): el contenido de las variables no se modifica, pero el contenedor $sf_data almacena una versión modificada de cada variable. De esta forma, los datos de las variables se obtienen en crudo, a menos que se obtenga la versión modificada del objeto $sf_data. Se trata del valor por defecto de la opción, aunque se trata del modo que permite los ataques de tipo XSS.
  • both: a todas las variables se les aplica el mecanismo de escape. Los valores también están disponibles en el contenedor $sf_data. Se trata del valor recomendado, ya que solamente se está expuesto al riesgo si se utilizan de forma explícita los datos originales. En ocasiones, se deben utilizar los valores originales, por ejemplo para incluir código HTML de forma que se interprete en el navegador y no se muestre el código HTML. Si una aplicación se encuentra medio desarrollada y se cambia la estrategia del mecanismo de escape a este valor, algunas funcionalidades pueden dejar de funcionar como se espera. Lo mejor es seleccionar esta opción desde el principio.
  • on: los valores solamente están disponibles en el contenedor $sf_data. Se trata del método más seguro y más rapido de manejar el mecanismo de escape, ya que cada vez que se quiere mostrar el contenido de una variable, se debe elegir el método get() para los datos modificados o el método getRaw() para el contenido original. De esta forma, siempre se recuerda la posibilidad de que los datos de la variable sean corruptos.
  • off: deshabilita el mecanismo de escape. Las plantillas no pueden hacer uso del contenedor $sf_data. Si nunca se va a necesitar el sistema de escape, es mejor utilizar esta opción y no la opción por defecto bc, ya que la aplicación se ejecuta más rápidamente.

OPCIONES PARA scaping_method

  • ESC_RAW: no modifica el valor original.
  • ESC_ENTITIES: aplica la función htmlentities() de PHP al valor que se le pasa y utiliza la opción ENT_QUOTES para el estilo de las comillas.
  • ESC_JS: modifica un valor que corresponde a una cadena de JavaScript que va a ser utilizada como HTML. Se trata de una opción muy útil para escapar valores cuando se emplea JavaScript para modificar de forma dinámica el contenido HTML de la página.
  • ESC_JS_NO_ENTITIES: modifica un valor que va a ser utilizado en una cadena de JavaScript pero no le añade las entidades HTML correspondientes. Se trata de una opción muy útil para los valores que se van a mostrar en los cuadros de diálogo (por ejemplo para una variable llamada miCadena en la instrucción javascript:alert(miCadena);).

APLICANDO EL MECANISMO DE ESCAPE A ARRAYS Y OBJETOS

// Definición de la clase
class miClase
{
public function pruebaCaracterEspecial($valor = »)
{
return ‘<‘.$valor.’>’;
}
}

// En la acción
$this->array_prueba = array(‘&’, ‘<‘, ‘>’);
$this->array_de_arrays = array(array(‘&’));
$this->objeto_prueba = new miClase();

// En la plantilla
<?php foreach($array_prueba as $valor): ?>
<?php echo $valor ?>
<?php endforeach; ?>
=> &amp; &lt; &gt;
<?php echo $array_de_arrays[0][0] ?>
=> &amp;
<?php echo $objeto_prueba->pruebaCaracterEspecial(‘&’) ?>
=> &lt;&amp;&gt;

Los métodos de los objetos a los que se aplica el mecanismo de escape aceptan un parámetro adicional:

<?php echo $objeto_prueba->pruebaCaracterEspecial(‘&’) ?>
=> &lt;&amp;&gt;
// Las siguientes 3 líneas producen el mismo resultado
<?php echo $objeto_prueba->pruebaCaracterEspecial(‘&’, ESC_RAW) ?>
<?php echo $sf_data->getRaw(‘objeto_prueba’)->pruebaCaracterEspecial(‘&’) ?>
<?php echo $sf_data->get(‘objeto_prueba’, ESC_RAW)->pruebaCaracterEspecial(‘&’) ?>
=> <&>

Las variables de Symfony también se modifican al activar el mecanismo de escape. Por tanto, las variables $sf_user, $sf_request, $sf_param y $sf_context siguen funcionando, pero sus métodos devuelven sus datos modificados, a no ser que se utilice la opción ESC_RAW como último argumento de las llamadas a los métodos.

YUI Compressor, compresor de archivos JavaScript

0

Habitualmente, cuando terminamos nuestros proyectos web, nos encontramos con archivos de javscript que pesan mucho, ya sea por los frameworks que usamos o por que parte de la lógica de la web depende de JavaScript. Para reducir el peso de esos archivos disponemos de YUI Compressor que nos permite comprimir los archivos JavaScript para que ocupen lo mínimo posible.

Características:

  • Renombra variables locales
  • Elimina espacios en blanco y cambios de líneas
  • Elimina comentarios
  • Compacta también CSS
  • Requiere Java 1.4 o superior

Forma de Uso:

  • Descompactamos el paquete descargado
  • A través de línea de comandos nos movemos al directorio “build”
  • Ejecutamos la siguiente línea de comandos, donde “archivo_original” es el camino completo archivo que deseamos comprimir y “archivo_comprimido” es el camino completo del archivo que resultará después de comprimido, si no existe se creará.

java -jar build/yuicompressor-2.4.2.jar archivo_original –o archivo_comprimido

YUI Compressor [Descargar]

Symfony: La vista (III), configuración de la vista

0

La vista en Symfony está dividida en dos partas:

  • Las plantillas (fragmentos de código): donde se recoge el resultado de la acción.
  • El resto: etiquetas meta, título de la página, archivos js y css, acciones que necesitan un layout personalizado (ventanas emergentes, publi) y las acciones que no necesitan layout alguno como las acciones para ajax.

Para modificar todo lo del segundo punto, que en general, podríamos considerar las cabeceras de la página, Symfony utiliza dos formas: a través del archivo de configuración view.yml o a través del objeto sfResponse para poder modificar las cabeceras de forma dinámica desde las acciones.

Si un mismo parámetro de configuración se establece mediante el objeto sfResponse y mediante el archivo view.yml, tiene preferencia el valor establecido mediante el objeto sfResponse.

EL ARCHIVO view.yml

editSuccess:
metas:
title: Edita tu perfil

editError:
metas:
title: Error en la edición del perfil

all:
stylesheets: [mi_estilo]
metas:
title: Mi sitio web

Esto anterior es la configuración de la vista de un módulo. Por defecto el archivo no existe y tendrías que crearlo y guardarlo dentro de la carpeta del módulo así: mimodulo/config/view.yml. Como puedes ver hay tres apartados:

  • editSuccess: Esta configuración se utilizará cuando la acción edit devuelva una respuesta igual a sfView::SUCCESS (o no devuelve nada, ya que es el valor devuelto por defecto).
  • editError: Esta configuración se utilizará cuando la acción edit devulva una respuesta igual a sfView::ERROR.
  • all: Esta es la configuración por defecto del módulo.

Para que veas la configuración en cascada de una aplicación en Symfony mira esto:

  • En apps/miaplicacion/modules/mimodulo/config/view.yml, las definiciones de cada vista solo se aplican a una vista y además sus valores tienen preferencia sobre las opciones generales del módulo.
  • En apps/miaplicacion/modules/mimodulo/config/view.yml, las definiciones bajo all: se aplican a todas las acciones del módulo y tienen preferencia sobre las definiciones de la aplicación.
  • En apps/miaplicacion/config/view.yml, las definiciones bajo default: se aplican a todos los módulos y todas las acciones de la aplicación.

Supongo que te estarás preguntando dónde se definen las cabeceras de la página, pues bien, estás se defienen en el archivo view.yml de la aplicación.

default:
http_metas:
content-type: text/html
metas:
title: symfony project
robots: index, follow
description: symfony project
keywords: symfony, project
language: en
stylesheets: [main]
javascripts: [ ]

has_layout: on
layout: layout

Más adelante explico las distintas opciones de la configuración de la vista. Antes veamos la segunda forma de configurar la vista.

EL OBJETO sfResponse

Aunque el objeto sfResponse pertenece a la vista, se puede acceder a él a través de la acción mediante el método getResponse. Algunos métodos que se utilizan habitualmente:

class mimoduloActions extends sfActions
{
public function executeIndex()
{
$respuesta = $this->getResponse();

// Cabeceras HTTP
$respuesta->setContentType(‘text/xml’);
$respuesta->setHttpHeader(‘Content-Language’, ‘en’);
$respuesta->setStatusCode(403);
$respuesta->addVaryHttpHeader(‘Accept-Language’);
$respuesta->addCacheControlHttpHeader(‘no-cache’);

// Cookies
$respuesta->setCookie($nombre, $contenido, $expiracion, $ruta, $dominio);

// Atributos Meta y cabecera de la página
$respuesta->addMeta(‘robots’, ‘NONE’);
$respuesta->addMeta(‘keywords’, ‘palabra1 palabra2’);
$respuesta->setTitle(‘Mi Página de Ejemplo’);
$respuesta->addStyleSheet(‘mi_archivo_css’);
$respuesta->addJavaScript(‘mi_archivo_javascript’); } }

Los métodos setter mostrados anteriormente que permiten dar un valor a la propiedad, también disponen de un método getter que devuelven el valor de la propiedad.

OPCIONES DE CONFIGURACIÓN DE LA VISTA

Copypasteo la introducción de esta sección del libro de Symfony:

Puede que hayas observador que existen 2 tipos diferentes de opciones para la configuración de la vista:

  • Las opciones que tienen un único valor (el valor es una cadena de texto en el archivo view.yml y el objeto respuesta utiliza un método set para ellas)
  • Las opciones que tienen múltiples valores (el archivo view.yml utiliza arrays para almacenar los valores y el objeto respuesta utiliza métodos de tipo add)

Hay que tener en cuenta por tanto que la configuración en cascada va sobrescribiendo los valores de las opciones de un solo valor y va añadiendo valores a las opciones que permiten valores múltiples. Este comportamiento se entiende mejor a medida que se avanza en este capítulo.

ETIQUETAS META

Las etiquetas <meta> se pueden definir dentro de las claves http_metas: y metas: en el archivo view.yml, o utilizando los métodos addHttpMeta() y addMeta() del objeto sfResponse dentro de la acción:

http_metas:
cache-control: public
metas:
description: Página sobre economía en Francia
keywords: economía, Francia

$this->getResponse()->addHttpMeta(‘cache-control’, ‘public’);
$this->getResponse()->addMeta(‘description’, ‘Página sobre economía en Francia’);
$this->getResponse()->addMeta(‘keywords’, ‘economía, Francia’);

Para las etiquetas <meta>, se puede añadir al método addHttpMeta() (y también a setHttpHeader()) un tercer parámetro con un valor de false para que añadan el valor indicado al valor que ya existía y así no lo reemplacen.

$this->getResponse()->addHttpMeta(‘accept-language’, ‘en’);
$this->getResponse()->addHttpMeta(‘accept-language’, ‘fr’, false);
echo $this->getResponse()->getHttpHeader(‘accept-language’);
=> ‘en, fr’

Para añadir las etiquetas <meta> en la página que se envía al usuario, se deben utilizar los helpers include_http_metas() e include_metas() dentro de la sección <head>.

EL TÍTULO DE LA PÁGINA

indexSuccess:
metas:
title: Los tres cerditos

$this->getResponse()->setTitle(sprintf(‘Los %d cerditos’, $numero));

El título de la página se puede incluir en el layout a través del método include_metas(), a través de include_title() o ambos, ya que es totalmente válido tener una etiqueta <meta name=»title»> o una etiqueta <title>.

INCLUIR ARCHIVOS

indexSuccess:
stylesheets: [miestilo1, miestilo2]
javascripts: [miscript]

$this->getResponse()->addStylesheet(‘miestilo1’);
$this->getResponse()->addStylesheet(‘miestilo2’);
$this->getResponse()->addJavascript(‘miscript’);

La extensión de los archivos no es necesario ponerla, a no ser que tengan una extensión diferente a la habitual (.css para archivos de estilos, .js para archivos javascript).

La inclusión de los archivos en la cabecera de la página es automática, no se necesita ningún método para añadirlos.

Recuerda que se sigue aplicando la configuración en cascada, por tanto los archivos que añadas a view.yml de la aplicación se mostrarán en todas las páginas de la aplicación.

view.yml de la aplicación:

default:
stylesheets: [principal]

view.yml del módulo:

indexSuccess:
stylesheets: [especial]

all:
stylesheets: [otra]

Si no se quiere incluir un archivo definido en alguno de los niveles de configuración superiores, se puede añadir un signo – delante del nombre del archivo en la configuración de más bajo nivel.

Ejemplo de archivo view.yml en el módulo y que evita incluir algunos de los archivos incluidos desde el nivel de configuración de la aplicación:

indexSuccess:
stylesheets: [-principal, especial]

all:
stylesheets: [otra]

Para eliminar todas las hojas de estilos o todos los archivos de JavaScript, se puede utilizar la siguiente sintaxis:

indexSuccess:
stylesheets: [-*]
javascripts: [-*]

Se puede ser todavía más preciso al incluir los archivos, ya que se puede utilizar un parámetro adicional para indicar la posición en la que se debe incluir el archivo (sólo se puede indicar la posición primera o la última):

# En el archivo view.yml
indexSuccess:
stylesheets: [especial: { position: first }]

// En la acción
$this->getResponse()->addStylesheet(‘especial’, ‘first’);

Para modificar el atributo media de la hoja de estilos incluida, se pueden modificar las opciones por defecto de Symfony:

indexSuccess:
stylesheets: [principal, impresora: { media: print }]

$this->getResponse()->addStylesheet(‘impresora’, », array(‘media’ => ‘print’));

Html devuelto por Symfony:

$this->getResponse()->addStylesheet(‘impresora’, », array(‘media’ => ‘print’));

CONFIGURACIÓN DEL LAYOUT

Normalmente Symfony, por defecto, utilizará la plantilla guardada en la carpeta /templates de la aplicación llamada layout.php, pero podemos indicarle cualquier otro layout:

indexSuccess:
layout: mi_layout

$this->setLayout(‘mi_layout’);

Si no se necesita ningún layout, se puede eliminar:

indexSuccess:
has_layout: false

$this->setLayout(false);

¿Cómo abro una ventana de MS-DOS desde una carpeta concreta?

2

Esa es la pregunta que, cada vez que tenía que usar los comandos de MS-DOS me venía a la mente, y supongo que a muchos de vosotros también os haya pasado. Pues bien, hoy tengo una solución para esa pregunta que todo usuario se ha hecho alguna vez:

  1. Abrimos el editor del registro de Windows. (regedit.exe)
  2. Buscamos la siguiente carpeta: HKEY_CLASSES_ROOT\Directory\shell
  3. Aquí creamos una clave (os creará una carpeta nueva) y la llamamos por ejemplo «Consola»
  4. Asegurate de estar en la carpeta «Consola». A la derecha, debajo de la columna «Nombre» te aparecerá este texto: «(Predeterminado)», pulsa ocn el botón derecho del ratón encima del texto y pulsa modificar.
  5. En la ventana que te aparezca escribe como valor: «Abrir un terminal de MS-DOS aquí». Este será el texto que aparecerá en nuestro menú contextual.
  6. Crea otra clave (otra carpeta) llamada «command» y dale el siguiente valor: «cmd.exe /k «cd %L»» (cd %L debe ir entre comillas dobles).
  7. Cierra RegEdit. Ve a cualquer carpeta y con el cursor sobre ella pulsa el botón derecho, te aparecerá el texto que acabamos de incluir en el registro y si lo pulsas se abrirá una consola de MS-DOS con la ubicación de esa carpeta.

Vía: http://yatocaba.wordpress.com/2009/05/01/truco-windows-abrir-terminal-en-una-carpeta-concreta/

Symfony: La vista (II), ayudantes

0

Los ayudantes o helpers son funciones PHP que permiten agilizar ciertas tareas repetitivas, devuelven código HTML y se utilizan en las plantillas Por ejemplo:

<?php echo input_tag(‘nick’) ?> => <input type=»text» name=»nick» id=»nick» value=»» />

La función input_tag(nombre, valor) genera el código para crear un campo de texto de un formulario con sus atributos básicos (aunque se pueden añadir otros atributos como tercer parámetro en la función). Algunos helpers disponen de cierta inteligencia:

<?php echo auto_link_text(‘Por favor, visita nuestro sitio web www.ejemplo.com’) ?> => Por favor, visita nuestro sitio web <a href=»http://www.ejemplo.com»>www.ejemplo.com</a>

Los helpers deben ser declarados, ya que al ser funciones y no clases no se cargan directamente. Para declarar un helper se hace uso de la función use_helper(‘nombre_del_helper1’, ‘nombre_del_helper2’):

Esta plantilla utiliza un grupo de helpers específicos <?php use_helper(‘Text’) ?> … <h1>Descripción</h1> <p><?php echo auto_link_text($descripcion) ?></p>

Si se quieren añadir más helpers hay que seperarlos con comas. Los helpers pueden ser cargados automáticamente utilizando el archivo de configuración settings.yml. De los siete helpers existentes en Symfony, cuatro (Helper, Tag, Url y Asset) no se pueden eliminar del archivo de configuración, pero los otros tres (Partial, Cache, Form) sí.

Los siete helpers:

  • Helper: se necesita para incluir otros helpers (de hecho, la función use_helper() también es un helper
  • Tag: helper básico para etiquetas y que utilizan casi todos los helpers
  • Url: helpers para la gestión de enlaces y URL
  • Asset: helpers que añaden elementos a la sección <head> del código HTML y que proporcionan enlaces sencillos a elementos externos (imágenes, archivos JavaScript, hojas de estilo, etc.)
  • Partial: helpers que permiten incluir trozos de plantillas
  • Cache: manipulación de los trozos de código que se han añadido a la cache
  • Form: helpers para los formularios

Los helpers más habituales:

/ Grupo Helper
<?php use_helper(‘NombreHelper’) ?>
<?php use_helper(‘NombreHelper1’, ‘NombreHelper2’, ‘NombreHelper3’) ?>

// Grupo Tag
<?php echo tag(‘input’, array(‘name’ => ‘parametro’, ‘type’ => ‘text’)) ?>
<?php echo tag(‘input’, ‘name=parametro type=text’) ?> // Sintaxis alternativa para las opciones
=> <input name=»parametro» type=»text» />
<?php echo content_tag(‘textarea’, ‘contenido de prueba’, ‘name=parametro’) ?>
=> <textarea name=»parametro»>contenido de prueba</textarea>

// Grupo Url
<?php echo link_to(‘Pínchame’, ‘mimodulo/miaccion’) ?>
=> <a href=»/ruta/a/miaccion»>Pínchame</a> // Depende del sistema de enrutamiento

// Grupo Asset
<?php echo image_tag(‘miimagen’, ‘alt=imagen size=200×100’) ?>
=> <img src=»/images/miimagen.png» alt=»imagen» width=»200″ height=»100″/>
<?php echo javascript_include_tag(‘miscript’) ?>
=> <script language=»JavaScript» type=»text/javascript» src=»/js/miscript.js»></script>
<?php echo stylesheet_tag(‘estilo’) ?>
=> <link href=»/stylesheets/estilo.css» media=»screen» rel=»stylesheet» type=»text/css» />

Por último, existe una manera de acceder a los helpers desde otro punto de la aplicación que no sea una plantilla, mediante la función sfLoader::loadHelpers($helpers).

Smooth criminal de Michael Jackson tocado a dos chelos

0

El vídeo que os dejo hoy muestra de lo que son capaces dos de los mejores chelistas del mundo (Stjepan Hauser y Luka Sulic). Disfrutadlo xD.

Ir arriba