Poesía binaria

Una de las grandes utilidades que nos da Facebook por si creamos una aplicación de escritorio, o una aplicación web que publique posts de nuestro blog automáticamente en nuestro muro, son los mensajes Offline, con este modo, no es necesario que un usuario esté identificado realmente en Facebook, aunque, debemos tener cuidado a la hora de trabajar con la aplicación, los usuarios nos han dado permiso para publicar en su nombre contenidos que nosotros generamos, por lo que debemos evitar que se pueda acceder a la publicación de contenidos directamente. Es decir, lo que voy a mostrar ahora es un mero ejemplo de cómo se haría, aunque muestro un programa que es lo más inseguro del mundo, ya que, cualquiera que entre en la dirección web especificada podrá escribir en Facebook con nuestro ID de usuario.

Creando la aplicación y practicando la publicación

Para esto, hay dos posts anteriores que te recomiendo leer si no lo has hecho ya:

• Creando una aplicación de Facebook, paso a paso
• Escribiendo en muros desde nuestra aplicación de Facebook

Creando dos interfaces

Por un lado necesitamos la interfaz que conecta con Facebook, tal y como la hemos hecho ya en el post anterior, desde aquí se pedirá permiso para poder publicar mensajes, y para poder acceder de forma offline. Este será nuestro index.php en los ejemplos (aunque podemos cambiarlo por cualquier página que destinemos a la identificación en Facebook).

Por otro lado, necesitamos el script que realmente va a publicar texto en Facebook, este script no debe identificarse en el sistema, sólo debe enviar la publicación (será en el ejemplo publica.php)

El código fuente completo podrás verlo y descargarlo al final del post.

Pidiendo permiso

Para escribir en Facebook con el modo offline, debemos pedir el permiso, concretamente el permiso offline_access. Con este permiso la palabra clave que nos da acceso con el usuario elegido no caducará (las claves normales, sin offline access, tienen una caducidad limitada, aunque funcionarán durante un tiempo (¿minutos?) aunque el usuario haya dejado de estar activo).

Para manejar los permisos de Facebook de una mejor forma, he extendido la clase Facebook con algunos métodos que nos ayudarán a la hora de pedir permisos:

Esta clase, se encargará de preguntar por los permisos que necesitamos de forma automática (en realidad fue como se explicó en el post anterior, aunque cuando tenemos que preguntar por varios permisos nuestro código puede crecer bastante).

Ahora, para pedir permiso haremos lo sigueinte:

La excepción podemos crearla como queramos, yo he seguido la técnica del post anterior, que podréis observar mejor con el código completo, lo que está claro es que el código no debe continuar pasado este punto, y debemos pedir los permisos necesarios. Además, a la hora de pedir los permisos, con la clase que hemos visto anteriormente, podemos hacer lo siguiente:

Con lo que también nos ahorramos unas líneas de código.

También, para publicar en nombre de los usuarios debemos obtener un Access Token, es una palabra de acceso única que identifica al usuario de Facebook en nuestra aplicación y nos permite interactuar, para ver esta palabra debemos hacer:

Publicando contenido

Para publicar contenido, ahora hemos creado el archivo publica.php que sólo publicará contenido en el muro, con este archivo tenemos que tener especial cuidado, ya que en este caso, cualquiera podrá publicar contenido nada más accediendo al archivo (Código fuente de publica.php):

Ahora, para publicar contenido, en la llamada a la API debemos especificar:

• uid = UID con la que queremos publicar, es decir, el usuario en nombre de quién hablamos.
• message = Mensaje que queremos publicar
• access_token = Palabra de acceso

Es más, podemos publicar en el muro o la página de quien queramos con esta técnica, igual que hacíamos antes, pero en este caso, lo hacemos sin que tengamos que estar identificados como ese usuario.

Código fuente de index.php

Para descargar el código fuente: modooffline.tar.bz2 (1.7Kb)
Hay que incluir la API de Facebook para que funcione y sustituir $api_key y $api_sec por nuestra API Key y API secret respectivamente.

Foto: Samuel M. Livingston (Flickr)

He decidido hacer esta guía porque Facebook anda cambiando los métodos para hacer aplicaciones y varias partes de su API. Los chicos de Facebook no paran de meter y sacar cosas y no dejan la página quieta. Después de hacer varias guías para “publicar definitivamente” en Facebook, van y cambian la forma de hacerlo.

Aunque parece que se han estabilizado, todos estos cambios han sido para llegar a la Graph API, se ha quedado bien hecha y estable, y yo creo que es posible aprender mucho de ella.

Aunque en esta guía empezaré desde el principio, desde que se crea la aplicación, paso a paso, ya que actualmente crear una aplicación vale para muchas cosas, no sólo para algo que resida dentro de Facebook sino para webs o clientes que funcionan fuera de Facebook e interactúan con la red social.

He de decir también que esta guía está hecha en Enero de 2012, por lo que si entras aquí en el futuro, puede que hayan hecho otro cambios definitivo más en Facebook.

Primer paso: Crear la App

Para ello debemos dirigirnos a https://developers.facebook.com/apps. Éste será nuestro centro de control de aplicaciones, donde podremos ver y editar los datos de éstas. Allí encontraremos en la parte superior de la página:

Pulsamos sobre Create New App, tras ello veremos un diálogo como este:

En el que en:

• App Display Name debemos decir el nombre de nuestra aplicación, o si es una aplicación para identificarnos en una página, el nombre de la página. Es un nombre que la identifique.
• App Namespace es el nombre que tiene nuestra aplicación en la URL de aplicaciones de Facebook. Es decir https://apps.facebook.com/AppNamespace . Dependiendo del ámbito de nuestra aplicación (si es accesible a través de Facebook.com o no) rellenaremos este campo o no.

Si continuamos, a veces la web de Facebook dará un error (comprobado el 7 de Enero de 2012), por lo que podemos volver a la página de las aplicaciones y continuar.

En la configuración de la aplicación, le damos a Edit Settings, y saldrá una pantalla así:

Aquí podremos rellenar el Namespace (mencionado antes), el mail de contacto y el dominio donde está alojada la aplicación (muy importante, ya que si la aplicación no está en el dominio indicado, no funcionará; además de la categoría de nuestra aplicación.

Por otra parte, arriba vemos la App ID y la App Secret. La primera es el identificador de nuestra aplicación, y la segunda una clave secreta que no se debe compartir con nadie para que la aplicación pueda interactuar con Facebook, algo así como el nombre de usuario y contraseña de nuestra aplicación. (Yo lo he puesto aquí, pero en realidad lo he regenerado varias veces).

La aplicación que crearemos servirá para enlazar una página web con Facebook y poder utilizar esa información, para eso debemos rellenar el apartado App Domain (por ejemplo minutodecaos.com), con el dominio donde estén alojadas las páginas de la aplicación, si no, la aplicación no estará autorizada y, un poco más abajo Site URL con la dirección exacta donde estará alojada nuestra aplicación.

Código fuente de la App

Es hora de crear nuestra aplicación en PHP. Lo primero que tenemos que hacer es descargarnos los archivos de la API desde esta dirección, dentro de GitHub. En principio trabajaremos en la web en modo local, por lo que creamos un directorio en nuestro disco duro (proyectos/facebook/tests/ dentro de mi home) Y descomprimimos los archivos dentro del directorio de nuestro proyecto. Aunque no es estrictamente necesario, yo lo he descomprimido dentro de lib/facebook, por lo que esos archivos estarán en $HOME/proyectos/facebook/tests/lib/facebook; y creamos el siguiente index.php (que luego subiremos al servidor junto con los ficheros de biblioteca de Facebook) :

Este código nos mostrará, la primera vez que entremos: “No estamos identificados en Facebook. Click aquí para identificarte”, eso no significa que no hayamos entrado a la página de Facebook, significa que la página web no te ha identificado como usuario y de ser autorizada, por eso hacemos click en la pantalla anterior y aparecerá lo siguiente:

Login automático

Si no queremos mostrar el enlace para identificarnos en la aplicación, podemos utilizar el siguiente código:

Mostrando datos de usuario, o cogiéndolos

En la parte de “Estamos identificados en Facebook”, podemos hacer:

Con estas líneas podemos ver información del usuario que está actualmente identificado en nuestra aplicación, y podremos utilizar los datos del array $userData:

• ['name'] - Nombre completo del usuario
• ['first_name'] - Nombre
• ['last_name'] - Apellidos
• ['link'] - Enlace a la página del usuario en Facebook
• ['username'] - Nombre de usuario de Facebook
• ['about'] - Frase personal
• ['gender'] - Género
• y mucho más que podemos ver cuando ejecutamos el ejemplo anterior

Ahora en Facebook, siempre que queramos acceder a información tanto de páginas, grupos, usuarios, etc, sólo tenemos que acceder a través de la llamada a api(’/localizacion’), con la palabra especial /me, como hemos visto para el usuario actual. Esto nos puede ayudar a identificarnos en nuestra web, sin pedir usuario, ni contraseña, a través de la Graph Api.

En ocasiones, sobre todo en nuestros paneles de administración, a veces es necesario, o bonito, conocer cuánto tiempo lleva el servidor encendido, así vemos si nos han reseteado la máquina o incluso alardear de que nuestro servidor lleva encendido más tiempo que otro.

Para ello, yo uso este código:

Donde obtenemos en un array los días, horas, minutos y segundos, directamente podemos hacer:

Si quieremos una salida bonita, podemos hacer lo siguiente:

cuenta() es una función que hice hace mucho mucho tiempo y a la que le tengo mucho cariño, y me ayuda a hacer la salida más amigable para el usuario. Aunque tenéis el comentario para Doxygen encima, aquí relato sus argumentos:

• $numero : Es el número que vamos a mostrar por pantalla, puede ser cualquier número
• $singular : Muestra la unidad en la que está expresado el número, además, este texto se mostrará sólo si el número es 1.
• $plural : Es igual que el anterior, pero se mostrará cuando la unidad es distinto a 1.
• $coma : Es un texto que se representa antes de la unidad, por ejemplo una coma, si vamos a enumerar, como en este ejemplo del uptime
• $sicero : Este texto se mostrará si $numero es 0
• $desp : Será un texto que se muestre después de la cadena generada

La función getUptime() producirá una excepción en servidores Windows o, en sistemas donde no tengamos acceso a /proc/uptime ; por supuesto el cliente puede estar corriendo cualquier sistema operativo.

Hace tiempo hablábamos de capturar señales, aunque en ocasiones, es necesario saber quién me envía esa señal, si por ejemplo nos envían un SIGINT o SIGTERM, tal vez queremos saber qué proceso nos quiere muerto y qué usuario lo ha invocado. O tal vez estamos esperando una señal de control (SIGUSR1, por ejemplo) por parte de un proceso cliente específico.

El problema es que por nuestro modo actual de direccionar señales (con signal(señal, funcion)) sólo comunicamos el número de señal que se ha recibido, sin más información.

Para capturar esta información necesitamos utilizar sigaction para establecer la función a la que llamaremos cuando llegue la señal, para utilizarla podemos utilizar el siguiente código:

Como vemos sigaction tiene 3 parámetros:

• La señal que queremos capturar
• Un registro de tipo struct sigaction
• La acción que se ejecutaba antes, por si queremos guardarla para restaurarla más tarde

Dentro del registro, tendremos como valores importantes (struct sigaction act):

• sact.sa_sigaction : que especifica la función que la llamaremos, esta función será del tipo void funcion(int, siginfo_t*, void*), donde el primer int recibirá la señal que nos han enviado (tal y como hacía la función que asignábamos con signal), el segundo parámetro será información asociada a la señal, y la tercera el contexto de ejecución.
• sact.sa_handler : será la función a la que se llama, es la misma que cuando hacemos signal(señal, funcion)
• sact.sa_flags : Es un conjunto de flags, si especificamos SA_SIGINFO, estaremos dando paso a la función especificada por sa_sigaction, si no utilizaremos sa_handler. Aunque esta variable vale para más cosas, para esta práctica nos vale con saber esto. (man sigaction para más info)
• sact.sa_mask

: Nos proporciona una máscara de las señales que serán bloquedas, podemos utilizar sigfillset() para rellenar toda la máscara automáticamente. Si queremos que unas se bloqueen y otras no podemos utilizar sigaddset() y sigdelset()

Ahora bien, la función que se llamará cuando venga una señal tendrá el prototipo que hemos visto antes con tres parámetros: la señal recibida, la información de la señal con un puntero a siginfo_t y el contexto de ejecución, que se pasará con un puntero a void, que por ahora no utilizaremos. La estructura que controla la información de la señal entre otros muchos datos nos facilitará lo siguiente:

• si_pid : PID que nos envía la señal (y esta acción da título al post)
• si_uid : Usuario que ejecuta el proceso que nos manda la señal
• si_errno : Algún error que haya causado la señal
• … para más información, man sigaction

Para preparar la sentencia tendremos que escribir varias líneas definiendo los valores del registro así como la llamada a la función sigaction(), por lo tanto podremos crear una función que tenga los parámetros más comunes a la hora de definir este tipo de acciones, así lo llamamos como a signal():

En esta función es importante poner bien el prototipo de la función como parámetro, eso lo comenté en un post anterior sobre callbacks

Ahora, vamos a dejar el código más bonito, este programa implementará el control de errores y nos permitirá salir cuando recibamos 5 SIGINT (pulsemos 5 veces control+C):

En ocasiones, estamos desarrollando una aplicación, y ésta necesita que le pasemos como parámetro, por ejemplo, una contraseña. El gran peligro que esto tiene es que cualquier usuario, pidiendo un listado de procesos con ps podrá ver la contraseña.

Imaginemos que tenemos una aplicación (que hemos hecho nosotros) que conecta con un servidor, y dado que hemos hecho un script para automatizar el proceso, el nombre de usuario y contraseña los pasaremos como parámetro al ejecutable. Dicho proceso se llama “aplicacionsegura”, dicho programa lo hemos lanzado en un servidor y otros usuarios tendrán acceso a dicha máquina. Ahora uno de ellos ejecuta lo siguiente:

$ ps ax
….
10560 pts/3    S+     0:00 ./aplicacionsegura –user=usuario –passwd=micontraseña
…

¡Nuestro gozo en un pozo! Otro usuario ya tiene nuestra contraseña, y ha sido muy sencillo. Y además lo podremos ver (de hecho ps es lo que hace) viendo el archivo /proc/PID/cmdline. Aunque debemos ver qué opciones tenemos:

Modificar el parámetro passwd

Para ilustrar el ejemplo, vamos a fijar la posición de –passwd=xxxxx al segundo parámetro (la captura de parámetros no es objeto de este post). Lo primero que vamos a probar es introducir un terminador en las cadenas de los parámetros, Si la cadena empieza por ‘\0′ estará vacía:

Aunque tardaremos poco en darnos cuenta que da igual, por una parte, no podríamos borrar todos los rastros de información, ya que si escribimos en la posición 0 de la cadena “–passwd=micontraseña” un terminador, el resto de la cadena se quedará en memoria y podrá ser leída. De todas formas, la cadena parece que sólo tiene un espacio para ps, es más, el \0 le ha dado igual.

Probemos ahora escribiendo “HOLA” en la cadena de la contraseña (ahora sí pongo el código completo, test.c):

Ahora ejecutaremos lo siguiente:

$ gcc -o test test.c
$ ./test & # El programa test esperará una tecla para terminar, pero lo ejecutaremos de fondo, para que no se cierre.
$ ps ax
….
10809 pts/3 S+ 0:00 ./test –user=usuario –passwd=HOLA traseña
….
$ killall test # Para matar el proceso

Un efecto curioso, las cadenas de los parámetros no son NULL-terminated, de cara a /proc/PID/cmdline por lo que cuando ponemos un terminador, lo toma como un espacio. Y se ve parte del parámetro. Lo que sí podemos hacer es sustituir por asteriscos, tantos asteriscos como letras tenga el parámetro.

Ahora al ejecutar ps:

$ ps ax
…
10906 pts/3 S+ 0:00 ./test –user=******* –passwd=*************
…

Aunque esta forma revela en cierto modo la longitud de las contraseñas y el nombre de usuario, puede que no nos interese, que queramos eliminar el parámetro entero y que no se vea:

La manera rápida pero peligrosa y de andar por casa

El objetivo es escribir algo más largo que el último parámetro. Es decir, si el parámetro de contraseña tiene 22 letras, tenemos que escribir algo más grande, unas 23 letras, o cargarnos el terminador del segundo argumento (no son NULL-terminated, el kernel sabe dónde empieza y dónde termina la cadena, pero hay un NULL para comprobar que todo va bien).

En este caso podemos hacer:

y veremos cómo ps no nos dice nada, en principio no es demasiado elegante, nos estamos cargando un terminador, que nosotros podríamos necesitar, para lectura, y estamos escribiendo en una zona de memoria que no es nuestra, ya que el argumento tiene reservado un tamaño de memoria, y estamos escribiendo más de lo que debemos (podemos producir una violación de segmento).

Decirle al kernel que no queremos los parámetros

Parecida a la forma anterior, podemos hacer:

lo que no es intuitivo para nada, porque nos estamos cargando el terminador, que controla el paso de parámetros. De esta forma, no tendremos ningún parámetro. Tambén podemos hacer una forma general

De esta forma desaparecerán todos los argumentos de /proc/PID/cmdline ; sólo tendremos la ruta y el nombre del ejecutable, y nuestros datos, al menos por esta parte, estarán seguros.
Foto: marc falardeau (Flickr)

No suelo hacer un post sólo para enlazar un artículo, pero este me ha parecido interesante.

Y es que muchos vez un cambio a Linux como algo oscuro y siniestro, pero hay personas que consideramos el cambio a Windows como algo tremendamente difícil.

La pesadilla de cambiarse a Windows - Paraíso Linux

Personalmente, ¿ por qué uso Linux ?

• Me hace más productivo
• Me da más sensación de seguridad
• Me permite hacer más cosas
• Me gusta aprender algo cada día

Todo va mucho más allá de la filosofía del software libre.

Si usamos frecuentemente un archivo .netrc para almacenar nombres de usuario y contraseñas para servidores FTP, tal vez queramos utilizar esas mismas contraseñas para Konqueror sin necesidad de volver a escribirlas, ni almacenarlas en Kwallet (ya están en un sitio, ¿para qué meterlas en más lugares?). O tal vez se nos presente el siguiente problema, tenemos que conectar con un servidor FTP que permite conexiones anónimas, y al mismo tiempo el nombre de usuario (o la contraseña) que tenemos contiene el carácter arroba (@), tendríamos que meterlo en la barra de direcciones y al menos en KDE3.5.10 no nos deja hacerlo (no lo he probado en kde4), y la única forma rápida que se me ocurrió fue a través de .netrc.

Bien, si vamos a crear un archivo .netrc de primeras, leer esto, es un post de un proyecto que utilizaba .netrc para conectar donde se explica qué tiene que contener el archivo.

Luego editamos el archivo $HOME/.kde/share/config/kio_ftprc (si no existe lo creamos), por ejemplo con nano:

$ nano ~/.kde/share/config/kio_ftprc

e introducimos la siguiente línea:

EnableAutoLogin=true

Lo más fácil ahora es reiniciar KDE, pero yo opté por ejecutar lo siguiente:

$ dcopserver_shutdown
$ dcopserver

Como véis estoy utilizando dcop, esta solución es para KDE3, aunque supongo que para KDE4 habrá alguna solución sin usar dbus. Por otra parte, en mi sistema no uso KDE como gestor de ventanas, sólo utilizo algunas aplicaciones de KDE, por lo que no garantizo que se reinicie el gestor de ventanas.

Con esta solución, desde Konqueror pude abrir un FTP cuyo nombre de usuario contenía una arroba

Os dejo el código:

Con este script intentamos evitar que se detecte como la IP del usuario la de un proxy intermedio recorriendo todas las variables que podemos encontrar en $metodos.