lunes, 30 de mayo de 2016

Verificando problemas de conexión a servidores de correo externos

Administrar un servidor de correo tiene un poco de arte entre tanta técnica. Descubrir problemas una vez nuestro servidor dice que todo esta bien (Para aprender sobre lo que el servidor dice estar bien, Interpretación de maillog en Postfix es una lectura bastante recomendable) puede ser una tarea casi imposible que involucra otras aspectos de la comunicación entre servidores.

Por otra parte, al tratar con un servidor como Zimbra, los registros pueden ser extensos al punto de causar un poco de confusión. Sin embargo, el flujo de cualquier correo que se dirige a un servidor externo siempre debería terminar con lineas como las siguientes de parte del componente smtp de postfix:
May 30 08:55:54 mail postfix/smtp[51709]: A5E3A49215DB: to=<cuenta@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.21.27]:25, delay=2, delays=0.16/0/0.54/1.3, dsn=2.0.0, status=sent (250 2.0.0 OK 1464620154 s81si15913905ybb.199 - gsmtp)
Como puede verse, la línea en sí tiene la siguiente forma:
A5E3A49215DB: to=<cuenta@servicio.com>, relay=servidor_externo[ip_servidor_externo], delay=2, delays=0.16/0/0.54/1.3, dsn=2.0.0, status=sent (250 2.0.0 OK mensaje_opcional)
Tener en cuenta que mensaje opcional es bastante propio de cada servicio de correo, y suelen ser bastante diferentes:
May 30 08:54:19 mail postfix/smtp[51710]: C126C49A603B: to=<cuenta@yahoo.es>, relay=mx-eu.mail.am0.yahoodns.net[188.125.69.79]:25, delay=2.6, delays=0.04/0.01/1.2/1.3, dsn=2.0.0, status=sent (250 ok dirdel)
May 30 08:53:22 mail postfix/smtp[12873]: 692BF4983168: to=<cuenta@hotmail.com>, relay=mx4.hotmail.com[65.55.92.168]:25, delay=5.2, delays=0.11/0.02/1.3/3.7, dsn=2.0.0, status=sent (250  <1740202306.276413.1464619995882.JavaMail.zimbra@dominio_local> Queued mail for delivery)
Pues que la costumbre podría llevarnos a conocer la respuesta específica de cada uno. Lo que cual puede ser importante ya que en cuento recibimos dicha respuesta, estamos complemente seguros de que el servidor externo ha recibido el correo. No queda de otra, que lo envíe a Spam ya es otra cuestión pero al menos sabemos no tenemos problemas de comunicación entre nuestro servidor y el de tal servidor del sistema de correo externo.

Ah, pero es posible que existan un problema si por "casualidad" tu proveedor ha configurado alguna especie de filtro de correo súper avanzado (Pero que irónicamente ya no tiene soporte). Porque en ese caso quién realiza la conexión con el servidor externo será dicho gateway y no tu servidor directamente. Lo cual te deja en la mala posición de no tener un control total sobre la forma en que se filtra tu correo. Con un filtro como este, es bastante difícil darse cuenta del problema ya que el mismo responde al componente smtp de nuestro servidor con un mensaje 250, y sin embargo no garantiza para nada que los correos pasen el filtro y mucho menos nos avisa de ello. Como si no fuera poco, este tipo de filtros de correos incumplen las normativas del protocolo porque no agregan cabeceras de su actividad en el correo, con lo que su detección se hace difícil. 

La forma más sencilla de verificar que la conexión a los servidores de correos externos es totalmente directa, es revisar la forma en que se empieza la negociación TLS con servidores en los que esto es posible (Lo que hoy en día constituyen la inmensa mayoría de servicios serios)
$ dig mx google.com.sv +short
10 google.com.s9a1.psmtp.com.
10 google.com.s9a2.psmtp.com.
10 google.com.s9b2.psmtp.com.
10 google.com.s9b1.psmtp.com.

$ openssl s_client -starttls smtp -crlf -connect google.com.s9a1.psmtp.com:25
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGoTCCBYmgAwIBAgIIbvTocO4F/oMwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTYwNTE4MTEwNzU4WhcNMTYwODEwMTA0NjAw
WjBnMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEWMBQGA1UEAwwNbXgu
Z29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJC2mSIn
I9NGj7WxngxCWH24lvQvVgNOA6ZZdkQkpcnD7mmXw78E0irxXnIuNjyu3OEVbkyK
XJdn+nBYRCiB5a7bUcIM2Z0T9uzfvaiJoEAAWnWkBi9o5Yr6At3VCR9JnHaU8RWD
VLo0JpROn+gJqQM64lF2X0PHo8sXFAnow3ySPBcSC3wthUrT0UptBW6EWh8vS4IL
4iWbsbKjpqPCMHaCmOPBz+tFqTeCuOlt5uC0f0PtNTzXG00pUffClrlTrRudRbkb
XVPncWJYoPSVO1HlLcBLHOCaUQS4rJKfrhnqXQTlEQSu0gH+UiiX2leq4kOtzNJv
/B4bBEycTZpAbqcCAwEAAaOCA20wggNpMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjCCAjkGA1UdEQSCAjAwggIsgg1teC5nb29nbGUuY29tghdhbHQxLmFz
cG14LmwuZ29vZ2xlLmNvbYIfYWx0MS5nbWFpbC1zbXRwLWluLmwuZ29vZ2xlLmNv
bYIdYWx0MS5nbXItc210cC1pbi5sLmdvb2dsZS5jb22CF2FsdDIuYXNwbXgubC5n
b29nbGUuY29tgh9hbHQyLmdtYWlsLXNtdHAtaW4ubC5nb29nbGUuY29tgh1hbHQy
Lmdtci1zbXRwLWluLmwuZ29vZ2xlLmNvbYIXYWx0My5hc3BteC5sLmdvb2dsZS5j
b22CH2FsdDMuZ21haWwtc210cC1pbi5sLmdvb2dsZS5jb22CHWFsdDMuZ21yLXNt
dHAtaW4ubC5nb29nbGUuY29tghdhbHQ0LmFzcG14LmwuZ29vZ2xlLmNvbYIfYWx0
NC5nbWFpbC1zbXRwLWluLmwuZ29vZ2xlLmNvbYIdYWx0NC5nbXItc210cC1pbi5s
Lmdvb2dsZS5jb22CEmFzcG14LmwuZ29vZ2xlLmNvbYIVYXNwbXgyLmdvb2dsZW1h
aWwuY29tghVhc3BteDMuZ29vZ2xlbWFpbC5jb22CFWFzcG14NC5nb29nbGVtYWls
LmNvbYIVYXNwbXg1Lmdvb2dsZW1haWwuY29tghpnbWFpbC1zbXRwLWluLmwuZ29v
Z2xlLmNvbYIRZ21yLW14Lmdvb2dsZS5jb22CGGdtci1zbXRwLWluLmwuZ29vZ2xl
LmNvbTBoBggrBgEFBQcBAQRcMFowKwYIKwYBBQUHMAKGH2h0dHA6Ly9wa2kuZ29v
Z2xlLmNvbS9HSUFHMi5jcnQwKwYIKwYBBQUHMAGGH2h0dHA6Ly9jbGllbnRzMS5n
b29nbGUuY29tL29jc3AwHQYDVR0OBBYEFIX2Hm9qeZHky5XG7V5xu7fBEovoMAwG
A1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUSt0GFhu89mi1dvWBtrtiGrpagS8wIQYD
VR0gBBowGDAMBgorBgEEAdZ5AgUBMAgGBmeBDAECAjAwBgNVHR8EKTAnMCWgI6Ah
hh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3JsMA0GCSqGSIb3DQEBCwUA
A4IBAQBBlIRHixSPzCY/GS+PHpc5wDMaquNvCLKFreEnMWkH7tN7lmcyC/f8G6Kq
rtR7TdD143pSGf0nxECNFV6QA6DdAKJZ/NWu5YVK/wL/FUHedNjLfO0jOXz7DoWX
M+T0hQmEwIRPHgjGN/WjDF0YiL73wLn3Ji1fYKcE/OVmSROqc7X2F7C03DxbikW5
fBjXOpRUc+pDVP2BqNRj/opS8VsXDRb7jr1QjEciWyui29tbhoG/byhvKn3SE2/J
ThABmqJo3gW5jwaKew/7R49pm2Vvxk4Nw5wAYLhHVbKHCRjZZtjZeVAU0uUtjk8i
8SvwX5g8pDqEhtsRi1aOWU5+AP56
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 4525 bytes and written 450 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: D413E1918D87A8E1CDCE37606F539CBF9CD6F79F1BED4F58D0B03E9801738ACF
    Session-ID-ctx: 
    Master-Key: 771FA531A831086DF2311DA9F6807FABAB77022421BEEA247A241766850C53AC85295112AC44250232E21A779A1B2985
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    0000 - 92 4d 45 c8 99 89 6f 92-27 10 30 69 a5 63 0f cd   .ME...o.'.0i.c..
    0010 - 1d f6 3e 72 43 a5 b3 ae-25 3a c6 94 e5 a2 df e1   ..>rC...%:......
    0020 - 92 76 d4 2d 4d cf 4b b9-f5 4c bd 4b 51 10 c8 48   .v.-M.K..L.KQ..H
    0030 - e5 a5 15 75 15 a1 92 bc-cd cb 64 c0 c9 5e c1 78   ...u......d..^.x
    0040 - 2d 51 13 82 d4 c6 cc 33-84 39 7e 09 85 9c 6b 26   -Q.....3.9~...k&
    0050 - d5 86 5b be 61 4c b0 95-64 07 0a 1d f6 5d 60 de   ..[.aL..d....]`.
    0060 - fe 37 21 58 d6 e9 35 a4-a3 90 76 63 2d e3 d0 ba   .7!X..5...vc-...
    0070 - 80 64 4f 5a 37 08 27 b4-7e 2c e9 eb 53 ab cd cc   .dOZ7.'.~,..S...
    0080 - e3 25 ad db 26 0e c8 27-7b d4 a2 c0 82 60 05 28   .%..&..'{....`.(
    0090 - 8f dd d6 d2 8d bf c0 18-72 c1 1c d0 85 21 72 92   ........r....!r.
    00a0 - 72 92 c1 8a                                       r...

    Start Time: 1464621046
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
250 SMTPUTF8
quit
221 2.0.0 closing connection w127si10551741ywc.301 - gsmtp
read:errno=0

viernes, 27 de mayo de 2016

Configurando TLS para envío a servidores externos en Zimbra

Desde hace un par de meses  para acá, a Google le pareció muy buena idea señalar a aquellos servicios de correos que no iniciaran TLS cuando se comunicarán con sus servidores:
Este infame candado rojo venía a decir que el dominio no era capaz de cifrar la comunicación cuando enviaba correos por el puerto 25 a gmail (Lo que dicho sea de paso es la forma en que esto ha funcionado toda la vida, el eterno chiste sobre la seguridad de nuestros correos electrónicos).
Para solventar este problema en zimbra, dependemos un poco de la versión:

  • Zimbra 8.6 (No lo he probé en versiones anteriores):
    Ya esta activado por defecto y todo bien.
  • Zimbra 8.0.6 (Cuidado con versiones anteriores, yo supondría que funciona de 8.0.6 en adelante)
    Es necesario correr configurarlo de la siguiente forma:
$ zmlocalconfig -e postfix_smtp_tls_security_level=may
$ zmlocalconfig -s postfix_smtp_tls_security_level
postfix_smtp_tls_security_level = may
Y con eso quedaría configurado. Lo más importante aparte de que ya no sale el candado rojo
 Y claro, las cabeceras han cambiado desde cuando no cifraba

 A algo más bonito e interesante
Por otra parte, el anterior correo es una especie de reenvío que hago de mi cuenta hacia mi cuenta de gmail, pero el correo enviado directamente se ve más bonito para google:

Fuentes:
Zimbra : Outbound smtp TLS encryption
Postconf keys
Using TLS for mail delivery from postfix to another TLS activated mail server
Best-Practice Recommendations for a Secure Zimbra Configuration

viernes, 20 de mayo de 2016

De como publicamos con pyramid una aplicación python

Todo el trabajo de ahora en adelante será el de usar la clase Usuarios como el core de nuestra aplicación, mientras que pyramid se encarga de publicarla webmente.

Básicamente, lo que se necesita es configurar las rutas en ./ambiente/aplicacion/aplicacion/__init__.py, mediante config.add_route()
    
    # Cuando request_method se encuentra acá, es devuelto un error como         
    # "The resource could not be found."                                        
    # Así que es como mejor configurar desde acá a request_method
    config.add_route('ficheros_listado', '/ficheros', request_method='GET')
Y luego escribir el controlador (Que acá se llaman vistas) para dicha ruta.
@view_config(route_name='ficheros_listado', renderer='json')                    
def ficheros_listado(request):                                                  
    """Cuando request_method se configura acà, el mensaje es diferente porque   
    la operación alcanzada es diferente                                         
        The resource could not be found.

predicate mismatch for view get_listar_ficheros (request_method = GET,HEAD)
    Por tanto lo mejor es configurarlo allá en __init__                         
    """                                                                         
    ficheros = Usuarios()                                                       
    listado = ficheros.listado()                                                
    return {'respuesta': listado}
Para no alargar demasiado, __init__.py queda de la siguiente forma:
# coding: utf-8                                                                 
from pyramid.config import Configurator                                         
                                                                                
                                                                                
def main(global_config, **settings):                                            
    """ This function returns a Pyramid WSGI application.                       
    """                                                                         
    config = Configurator(settings=settings)                                    
    # Cuando request_method se encuentra acá, es devuelto un error como         
    # "The resource could not be found."                                        
    # Así que es como mejor configurar desde acá a request_method               
    config.add_route('ficheros_listado', '/ficheros', request_method='GET')     
    config.add_route('ficheros_detalle', '/ficheros/{usuario}', request_method='GET')
    config.add_route('ficheros_creacion', '/ficheros', request_method='POST')   
    config.add_route('ficheros_modificacion', '/ficheros/{usuario}', request_method='PUT')
    config.add_route('ficheros_borrado', '/ficheros/{usuario}', request_method='DELETE')
    config.scan()                                                               
    return config.make_wsgi_app()
Y el fichero ./ambiente/aplicacion/aplicacion/views/actividades.py con las vistas (Que en realidad son controladores), queda de la siguiente forma:
# coding: utf-8
from pyramid.view import view_config
from ..fichero_app.ficheros import Usuarios
from pyramid import httpexceptions as exception

@view_config(route_name='ficheros_listado', renderer='json')
def ficheros_listado(request):
    """Cuando request_method se configura acà, el mensaje es diferente porque 
    la operación alcanzada es diferente
        The resource could not be found.


     predicate mismatch for view get_listar_ficheros (request_method = GET,HEAD)
    Por tanto lo mejor es configurarlo allá en __init__
    """
    ficheros = Usuarios()
    listado = ficheros.listado()
    return {'respuesta': listado}

@view_config(route_name='ficheros_detalle', renderer='json')
def ficheros_detalle(request):
    usuario = request.matchdict['usuario']
    ficheros = Usuarios()
    detalle = ficheros.detalle(usuario)
    return {'respuesta': detalle}

@view_config(route_name='ficheros_creacion', renderer='json')
def ficheros_creacion(request):
    try:
        usuario = request.json_body['usuario']
        data = request.json_body['data']
    except Exception as e:
        return exception.HTTPBadRequest()
    ficheros = Usuarios()
    creacion = ficheros.creacion(usuario, data)
    return {'respuesta': creacion}

@view_config(route_name='ficheros_modificacion', renderer='json')
def ficheros_modificacion(request):
    usuario = request.matchdict['usuario']
    try:
        data = request.json_body['data']
    except Exception as e:
        return exception.HTTPBadRequest()
    ficheros = Usuarios()
    modificacion = ficheros.modificacion(usuario, data)
    return {'respuesta': modificacion}

@view_config(route_name='ficheros_borrado', renderer='json')
def ficheros_borrado(request):
    usuario = request.matchdict['usuario']
    ficheros = Usuarios()
    borrado = ficheros.borrado(usuario)
    return {'respuesta': borrado}
Eso es todo. Con lo anterior nuestra clase Usuarios ha sido publicada a la web

Para ver que esto es cierto corremos el servidor web integrado desde el directorio raíz de la aplicación en ./ambiente/aplicacion (Que queda bien para desarrollo, pero no es la solución definitiva cuando lo vayamos a tirar en producción)
pserve development.ini --reload
En este punto ya podemos probar la aplicación desde la web. Bien podría ser desde un navegador, pero no. Como la idea es que esto funcione como una API, no deberíamos ocuparnos de crear interfaz web alguna, algo que sería necesario para verificar muchas de las operaciones que hemos definido. Lo más sencillo en este caso es crear las peticiones HTTP desde consola mediante curl, herramienta que sencillamente cambia la vida en cuanto se le toma práctica.
  • Para verificar el listado de ficheros en la raíz de ficheros/ mediante GET, especificamos el verbo HTTP con la opción -X
$ curl -X GET http://localhost:6543/ficheros -w "\n" 
{"respuesta": ["alortiz", "kpenate", "opineda"]}
  • Verifica la obtención de los datos particulares de un usuario en ficheros/{usuario}
$ curl -X GET http://localhost:6543/ficheros/alortiz -w "\n"
{"respuesta": {"palabras": ["ambiente", "publico"], "nombre": "Alexander", "apellido": "Ort\u00edz"}}
  • Creamos un usuario mediante el POST de ficheros/. Atención a como añadimos la cabecera content-type con -H,  y el valor que le hemos configurado. Luego, la opción -d nos permite configurar datos casi en bruto. El dato que enviamos es precisamente una cadena de texto que representa un JSON válido
$ curl -i -X POST http://localhost:6543/ficheros -w "\n" -H "content-type: application/json; charset=UTF-8" -d '{"data": {"palabras": ["estruendo", "epilepsia"], "nombre": "Francisco", "apellido": "Cornejo"}, "usuario": "fcornejo"}' 
{"respuesta": {"palabras": ["estruendo", "epilepsia"], "nombre": "Francisco", "apellido": "Cornejo"}}

$ curl -X GET http://localhost:6543/ficheros/fcornejo -w "\n"
{"respuesta": {"palabras": ["estruendo", "epilepsia"], "nombre": "Francisco", "apellido": "Cornejo"}}
  • Ahora modificamos al usuario fcornejo antes creado mediante el verbo PUT
$ curl -X PUT http://localhost:6543/ficheros/fcornejo -H "content-type: application/json" -d '{"data": {"palabras": ["esfuerzo", "historia"], "nombre": "Francisco", "apellido": "Cornejo"}, "usuario": "fcornejo"}' -w "\n"
{"respuesta": {"palabras": ["esfuerzo", "historia"], "nombre": "Francisco", "apellido": "Cornejo"}}
 
$ curl -X GET http://localhost:6543/ficheros/fcornejo -w "\n"
{"respuesta": {"palabras": ["esfuerzo", "historia"], "nombre": "Francisco", "apellido": "Cornejo"}}
  • Y por ultimo borramos al usuario fcornejo con el verbo DELETE
$ curl -X GET http://localhost:6543/ficheros -w "\n"
{"respuesta": ["alortiz", "kpenate", "opineda", "fcornejo"]}

$ curl -X DELETE http://localhost:6543/ficheros/fcornejo -w "\n"
{"respuesta": "fcornejo"}

$ curl -X GET http://localhost:6543/ficheros -w "\n"            
{"respuesta": ["alortiz", "kpenate", "opineda"]}

miércoles, 18 de mayo de 2016

La pequeña y estúpida aplicación fichero_app

Tomo un momento para hablar de una pequeña aplicación que vamos a integrar con pyramid. Integrar quizá no: Vamos a publicar la aplicación con pyramid.

Como se verá, la aplicación es totalmente funcional por si misma. Bueno, que si se quiere ver es una pequeña biblioteca, casi inútil desde un punto de vista práctico. Vamos, que ni siquiera esta capturando excepciones. Sin embargo, yo voy a suponer que esta aplicación es la joya de la corona, que dentro de cada función encierra grandes operaciones de tratamiento de ficheros que me gustaría que estuvieran disponibles para otras aplicaciones, sobre todo, para un cliente web que funcione con AngularJS

Con ustedes, la aplicación ficheros.py:
# coding: utf-8
 
import os
import json
 
class Usuarios():
    """ Manejo de usuarios por medio de ficheros json
    """

    def __init__(self):
        self.direccion = os.getcwd() + '/archivos/'
     
    def listado(self):
        """ Retorna lista con usuarios registrados
        Returns:
            listado: (list) Lista de usuarios registrados
        """
        try:
            lista = os.listdir(self.direccion)
            usuarios = [usuario.split('.')[0] for usuario in lista]
        except IOError as e:
            return {'error': e.args}
        return usuarios
     
    def detalle(self, usuario):
        """ Retorna diccionario con información de usuario
        Args:
            usuario: (str) usuario del que se desean detalles
        Returns:
            dict: Información del usuario
        """
        try: 
            fichero = open(self.direccion + '/' + usuario + '.json') 
            contenido = json.load(fichero)
        except ValueError as e:
            return {'error': e.message}
        except IOError as e:
            return {'error': e.args[1]}
        return contenido
    
    def creacion(self, usuario, datos):
        """ Retorna diccionario de datos con los que se ha creado al usuario
        Args:
            usuario: (str) nombre del usuario a crear
            datos: (dict) datos de la información del usuario
        Returns:
            dict: Datos con los que se ha creado al usuario
        """
        try:
            fichero = open(self.direccion + '/' + usuario + '.json', 'w')
            contenido = json.dump(datos, fichero)
        except ValueError as e:
            return {'error': e.message}
        except IOError as e:
            return {'error': e.args[1]}
        return datos
     
    def modificacion(self, usuario, datos):
        """ Retorna diccionario con los datos modificados del usuario
        Args:
            usuario: (str) nombre del usuario a modificar
            datos: (dict) datos a modificar del usuario
        Returns:
            dict: Datos con los que se ha creado al usuario
        """
        try:
            fichero = open(self.direccion + '/' + usuario + '.json', 'w+')
            contenido = json.dump(datos, fichero)
        except ValueError as e:
            return {'error': e.message}
        except IOError as e:
            return {'error': e.args[1]}
        return datos
    
    def borrado(self, usuario):
        """ Retorna nombre de usuario borrado
        Args: 
            usuario: (str) nombre del usuario a borrar
        Returns:
            usuario: (str) nombre del usuario borrado
        """
        try:
            fichero =  self.direccion + '/' + usuario + '.json'
            os.remove(fichero)
        except OSError as e:
            return {'error': e.args[1]}
        return usuario

Como puede intuirse del código, tenemos cinco operaciones definidas.
  • Listar los ficheros que se encuentran en ./archivos/ (listar())
  • Ver en detalle un fichero .json que se encuentra dentro de ./archivos/ (detalle()), y que básicamente consiste en retornar el contenido json del fichero traducido a un tipo python válido.
  • Crear un nuevo fichero json dentro de ./archivos/ (creacion())
  • Modificar un fichero json, reemplazando todo el contenido actual con el contenido que tiene las modificaciones ya aplicadas. Parece ser que la precisión en las definiciones es algo importante
  • Borrar un fichero json dentro de ./archivos/ 
Que sí, que me estoy inspirando en CRUD para hacer esto. Es una forma muy cómoda para pensar una aplicación.

Para empezar a usar la aplicación, bastaría con crear el directorio ./archivos/ junto con algunos ficheros de prueba. Pues que lo que viene a decir la documentación es que cada método de la aplicación recibe, en su mayoría, un usuario y un diccionario datos. Y en su mayoría retorna otro diccionario
$ mkdir ./archivos
$ echo '{"palabras": ["ambiente", "publico"], "nombre": "Alexander", "apellido": "Ort\u00edz"}' > ./archivos/alortiz.json
$ echo '{"palabras": ["contenido", "fichero"], "nombre": "Karen", "apellido": "Pe\u00f1ate"}' > archivos/kpenate.json
$ echo '{"palabras": ["posix", "permisos"], "nombre": "Olga", "apellido": "Pineda"}' > archivos/opineda.json
Por último, convertiremos esta diminuta aplicación en una paquete python válido. Tomando en cuenta lo sencillo que es en python: Creamos un directorio, ubicamos todos los ficheros creados dentro y creamos un ficheros __init__.py
$ mkdir ./fichero_app
$ mv archivos/ ficheros.py fichero_app/
$ touch fichero_app/__init__.py
Un script python que tenga el mismo directorio raíz que fichero_app (En este momento, ./ambiente/aplicacion/aplicacion/fichero_app), puede importar la clase Fichero de la siguiente forma:
from fichero_app.ficheros import Usuarios
La cuestión sobre el directorio a usar es un poco espinosa, producto de no parametrizarla como debiera. El truco es que la búsqueda del directorio ficheros ocurrirá en la base desde donde se ejecute la aplicación que llama a nuestra pequeña aplicación como módulo.

El siguiente paso va en la línea de la guía con Pyramid: De como publicamos con pyramid una aplicación python

lunes, 16 de mayo de 2016

Primeros pasos con Pyramid

Que quiero hacer con python una una aplicación web simple y precisa, que no consuma de una base de datos y que tampoco produzca HTML sino contenido JSON (Con lo puedo usar AngularJS para el respectivo cliente web). Así que decidí usar Pyramid, que tenía algunas de las cosas que a primera vista necesito (O más bien que creo necesitar).

La siguiente guía está en constante desarrollo. Básicamente estoy haciendo los primeros pasos después de revisar la guía oficial más completa
La recomendación oficial es crear un entorno virtual en el cual instalar los paquetes
$ virtualenv ambiente
$ cd ambiente/
Activamos el entorno, lo que no significa más que configurar unas cuantas variables del sistema para que usen el ambiente virtual, lo que puede verificarse por curiosidad al revisar el path correspondiente a pip
$ source bin/activate
$ which pip
/home/vtacius/public_html/ambiente/bin/pip
Lo siguiente será instalar pyramid, y para empezar bien y rápido, usaremos pcreate para el scaffolding (Término que no es del todo correcto en estas condiciones) de la aplicación
$ pip install pyramid
$ pcreate -s starter aplicacion
$ cd aplicacion/
Este nivel de la aplicación (./ambiente/aplicacion/) aprovechamos para cambiar el fichero setup.py para retirar en el arreglo requires a pyramid_chameleon porque es el paquete para producir HTML por medio de plantillas, y no pienso usarlo. Agregamos nose y webtest porque no se han incluido en el proyecto
import os

from setuptools import setup, find_packages

here = os.path.abspath(os.path.dirname(__file__))
with open(os.path.join(here, 'README.txt')) as f:
    README = f.read()
with open(os.path.join(here, 'CHANGES.txt')) as f:
    CHANGES = f.read()

requires = [
    'pyramid',
    'pyramid_debugtoolbar',
    'waitress',
    'nose',
    'webtest'
    ]

(...)
Ahora instalamos todos los paquetes requeridos por la aplicación en nuestro entorno virtual:
$ python setup.py develop
A este nivel (./ambiente/aplicacion/) hay que volver cuando se quiere realizar los test y correr waitress.

Ahora entramos dentro de nuestra aplicación propiamente, llamada aplicacion, y acomodamos según nuestras necesidades: eliminamos el directorio template y static porque no pienso usarlo, y volvemos un paquete a views porque planeo crecer con la aplicación aunque sea un poquito:
$ cd aplicacion/
$ rm -rf views.py templates/ static
$ mkdir views
$ touch views/__init__.py
Del fichero __init__.py eliminamos las referencias a pyramid_chameleon, y la configuración de contenido estático que nos es innecesaria:
    config.include('pyramid_chameleon')
    config.add_static_view('static', 'static', cache_max_age=3600)
Para este primer ejercicio, basta con crear un fichero en views/ de cualquier nombre (Sí, cualquier nombre, la magia de scan) de la siguiente forma:
# coding: utf-8
from pyramid.view import view_config

@view_config(route_name='home', renderer='json')
def get_actividad_list(request):
    return {'home': '¡Hola Mundo!'}
Volvemos un directorio atrás y corremos la aplicación:
$ pserve development.ini --reload
Ahora lo probamos, desde consola porque somos gente hardcore que odia a los navegadores (¡Muerte a los navegadores!)
$ curl -i -X GET http://localhost:6543
HTTP/1.1 200 OK
Content-Length: 29
Content-Type: application/json; charset=UTF-8
Date: Tue, 17 May 2016 04:11:18 GMT
Server: waitress


{"home": "\u00a1Hola Mundo!"}
Preparé una especie de test que sale más extenso que el código que se quiere testar, tendrá que valer para primer esfuerzo. El punto más discutible es el de la fixture, sin embargo la idea debería estar en ese sentido. El contenido de tests.py queda de la siguiente forma:
# coding: utf-8
from unittest import TestCase

from pyramid import testing

class ViewTests(TestCase):
    def setUp(self):
        self.config = testing.setUp()
        # Atentos a nuestro intento de fixture
        self.res_get_actividad_list = {'home': '¡Hola Mundo!'}

    def tearDown(self):
        testing.tearDown()

    def test_get_actividad_list(self):
        # Hacemos las importaciones acá en lugar de globalmente para que el test sea más sincero
        from .views.actividades import get_actividad_list
        peticion = testing.DummyRequest()
        respuesta = get_actividad_list(peticion)
        self.assertEqual(respuesta['home'], self.res_get_actividad_list['home'])

class ViewFunctionalTest(TestCase):
    def setUp(self):
        # Este método debería considerarse un __init__ más apropiado en la cuestión de testeo
        # Hacemos las importaciones acá en lugar de globalmente para que el test sea más sincero
        from aplicacion import main
        app = main({})
        from webtest import TestApp
      
        self.testapp = TestApp(app)

        # Atentos a nuestro intento de fixture
        self.res_get_actividad_list = {'home': u'¡Hola Mundo!'}
  
    def test_get_actividad_list(self):
        respuesta = self.testapp.get('/', status=200, xhr=True)
        # Es discutible que haga esto, supongo que me aseguro que no vaya a cambiar la respuesta por accidente
        self.assertEqual('application/json', respuesta.content_type) 
        # Trato de usar la fixture para verificar contenido ya conocido
        proposicion = self.res_get_actividad_list['home']
        self.assertEqual(respuesta.json_body['home'], proposicion)

Ahora corremos el test en el directorio raíz de la aplicación
(ambiente)vtacius@ilaria:~/public_html/ambiente/aplicacion> nosetests
..
Name                              Stmts   Miss  Cover   Missing
---------------------------------------------------------------
aplicacion.py                         8      0   100%   
aplicacion/tests.py                  25      0   100%   
aplicacion/views.py                   0      0   100%   
aplicacion/views/actividades.py       3      0   100%   
---------------------------------------------------------------
TOTAL                                36      0   100%   
----------------------------------------------------------------------
Ran 2 tests in 1.123s

OK
Claro, los test automatizados son realmente algo increíble. Apenas pueden reemplazar al hecho de usar curl desde consola, pero todo lo compensan con el hecho de ser automatizados.
El siguiente paso es revisar la aplicación que vamos a publicar por medio de pyramid: fichero_app

Otros apuntes interesantes

Otros apuntes interesantes