Mundial Brasil 2014 en Google Calendar

Simplemente debes ir a la versión web de Google Calendar en tu navegador, la cual es calendar.google.com. Allí debes pulsar sobre la opción que dice Otros Calendarios (haz clic en la pequeña flechita hacia abajo que está a lado). Allí deberás elegir la opción Añadir por URL.

Enseguida te aparecera una ventana emergente en donde tendras que pegar el enlace de datos de los horarios de Mundial Brasil 2014

COPIA Y PEGA ESTE ENLACE: 

https://www.google.com/calendar/feeds/vdmtdcektajkqjk51vvda4ni4k%40group.calendar.google.com/public/basic

Una vez realizado todos los pasos podras ver todos los horarios sobre los partidos del Mundial  como se lo mostrarmos a continuacion:

WWDC 2014

Apple ha presentando su nuevo lenguaje de programación llamado Swift que permite la edición de código en tiempo real.
Algo que nos tomo por sorpresa y que a muchos nos déjo con la cabeza estallando
Tim Cook no nos muestra a lo que generalmente estamos acostumbrados!!!
Nuevos dispositivos y otras cosas. Se tomaron su tiempo y nos muestran algo realmente sorprendete Swift la novedad de Apple.

Día histórico para la compañía: después de ver las novedades de iOS y OS X y las nuevas APIs que permite la integración y comunicación de aplicaciones de terceros, Apple ha presentado en el seno de la conferencia de desarrolladores, como no podía ser de otra forma, su nuevo lenguaje de programación cuyo nombre en clave es Swift, el nuevo lenguaje de programación de Apple.

Enfocado para aquellos que están empezando a programar totalmente compatible con Xcode, incluye guías y referencia para su compresión y las aplicaciones creadas con este lenguaje podrán ser enviadas a la App Store.

Libros para descargar

Despues de mucho tiempo vuelvo a bloguear para mis visitantes.
Esta vez con algo interesante para los amantes de los libros y
mas los desarrolladores o programadores
En esta ocasión compartire libros por los cuales tendrias que pagar
un monto monetario

Para descargar el libro haz click en los enlace que tienen sus nombres respectivos
Ojo no te olvides de las llaves para poder realizar las descargas

Angularjs

key: ZTyhZ1RaGKSwAC8HDWZ9xF3QV_Ug7AG8h5wwefoE0PQ

Este libro sobre #Angularjs es un de los mas completos que puedes llegar a encontrar

Autor: Brad Green

Nodejs

key: w7QqMwBg66FilXsWn_x1ff57o5QraL6-9KBwdudbkHM

El libro sobre #Nodejs es nada mas y nada menos que "The node Beginner book"

Html5 + CSS + Javascript

key: JgR3DGXv4etVjI9CI9Xx1GgVRwMcecW05ymS-i5zM8I

Este libro esta dedicado para las personas que buscan libros en español facil y practico

Bueno espero que les haya gustado y no se olviden de compartir y comentar sobre este post
Agradercer no esta demas..

QUE ES REST???

REST no es una tecnología, ni siquiera una arquitectura, sino una familia de arquitecturas. Cualquier arquitectura de servicios distribuidos que cumpla con una serie de requisitos se puede considerar como una arquitectura REST. Estos requisitos o propiedades son los siguientes:

• No se publican servicios RPC. En arquitecturas REST, los servicios no publican un conjunto arbitrario de métodos u operaciones. Por ejemplo, en REST no podemos publicar una interfaz “IGestionEmpleados” con métodos “addEmpleado”, “removeEmpleado” o “buscarEmpleadosEnEdadDeJubilacion”.
• En REST lo que se publica son recursos. Un recurso se puede considerar como una entidad que representa un concepto de negocio que puede ser accedido públicamente. Un ejemplo de recurso sería simplemente “EmpleadosDeLaEmpresa” y otro podría ser “Empleado número 33″
• Cada recurso, como buena entidad que se precie, y de acuerdo a los principios de OO, posee un identificador único y global, que lo distingue de cualquier otro recurso, aunque ambos tuvieran exactamente los mismos datos. En el caso de “Empleado 33″, este sería diferente de “Empleado 40″, aunque tuvieran el mismo nombre, sueldo, etc.
• Cada recurso posee un estado interno, que no puede ser accedido directamente desde el exterior. Lo que sí es accesible desde el exterior es una o varias representaciones de dicho estado. Por representación se entiende un formato de datos concreto usado para la transferencia de una copia del estado público del recurso entre el cliente y el servidor. La implementación del recurso decide que información es visible o no desde el exterior, y que representaciones de dicho estado se soportan. Una representación de “Empleado 33″ podría ser un documento XML con la información accesible de este. Otra representación sería un documento HTML y otra podría ser un JSON. No sólo podemos representar el recurso como datos estructurados, hay que echarle imaginación. Podríamos pedir por ejemplo, una representación en formato imagen PNG del recurso, tal vez esto devolvería una foto del empleado, o un gráfico de su productividad o su huella dactilar.
• Si no podemos definir operaciones arbitrarias sobre el recurso, ¿cómo podemos operar con él? En REST todos los recursos comparten una interfaz única y constante. Todos los recursos tienen las mismas operaciones. Las operaciones nos permiten manipular el estado público del recurso. En un sistema REST típico se definen cuatro operaciones.
• CREATE. En esta operación el cliente manda al servidor una petición para crear un nuevo recurso. Opcionalmente el cliente puede mandar una representación del estado inicial de este recurso. El servidor responde con el identificador global del nuevo recurso.
• DELETE. En esta operación el cliente elimina un recurso del servidor. El cliente necesita saber el identificador del recurso.
• READ. Con esta operación el cliente puede leer una representación del estado de un recurso, identificado con su identificador global. El cliente puede especificar que tipos de representaciones entiende. Aquí lo que ocurre realmente es que se copia el estado del recurso en el servidor y se pega en el cliente. Ambas copias del estado no se mantiene sincronizadas. El servidor puede cambiar el estado real del recurso y el cliente, de forma independiente, puede modificar su copia local del estado del recurso.
• UPDATE. Como el servidor y el cliente tienen una copia diferente del estado, el cliente puede usar esta operación para sobrescribir o grabar su copia del estado en el servidor. De esta manera se puede actualizar el estado del recurso con las modificaciones hechas en el cliente.
• La implementación del servicio es libre de prohibir alguno de estos métodos para un recurso en concreto. También debe definir el modelo de datos que se va a publicar y que representaciones soporta. Lo que no puede hacer es inventarse operaciones de forma arbitraria. Las operaciones son siempre las mismas.
• Los distintos recursos se pueden interrelacionar y referenciar entre si mediante sus identificadores globales.

Una confusión típica es pensar que REST no es más que un CRUD llevado a la web, ¿no será mi BBDD relacional un sistema REST? No exactamente. Es parecido, pero existen algunas diferencias sutiles e importantes entre un CRUD simple o una BBDD con una arquitectura REST:

• Al contrario que en un CRUD típico, como una BBDD, el servidor puede soportar muchas representaciones de un mismo recurso: xml, pdf, png, gif, excel, html, json, texto, comaereas, churros binarios, etc.. Hay pocas BBDD que hagan esto.
• No penséis que las operaciones REST se limitan a hacer CRUD tradicional, no se trata solo de persistir nuestros cambios. Cuando hacemos un UPDATE, nuestra implementación del recurso además de grabar el estado en soporte persistente, debe hacer otras cosas, como validaciones de negocio o actualizaciones en otros recursos para mantener la consistencia global del sistema. Esto sí que se parece a una BBDD con triggers e integridad referencial, pero no es CRUD en el sentido de que no nos limitamos a grabar y ya está. Una DAO es CRUD, un recurso REST no (excepto en los casos más simples).
• Los recursos mantiene interrelaciones entre si. La topología de estas interrelaciones es compleja, puede ser un grafo arbitrario, con ciclos, o un simple árbol. Es más, los recursos de nuestro sistema se pueden interrelacionar con recursos en sistemas de terceras partes, ya que el identificador es único y global.

Algunos estareis pensando: “¿Existe en la actualidad alguna arquitectura REST? Estas cosas tan modernas tardan un tiempo en madurar, y yo no quiero usar una tecnología que esté verde”. Pues resulta que REST es un enfoque maduro con un claro ejemplo existente en la actualidad: la world wide web, o web a secas. Veamos si la web tiene propiedades REST:

• La web está compuesta de recursos, cada página web puede considerarse un recurso.
• Cada recurso tiene un identificador único global, que es su URI (o URL para los antiguos o IRI para los más modernos). Usando una URL podemos llegar a cualquier recurso en la web.
• Dada una URI, y mediante el protocolo HTTP, podemos operar sobre estos recursos. La operación a realizar se especifica mediante el verbo HTTP. Mediante cabeceras especiales como Accept o Content-Type se puede especificar que representaciones entienden el servidor y el cliente y que representación se usa en un mensaje concreto para transporta el estado del recurso.
• El verbo GET hace la operación READ.
• El verbo DELETE hace la operación DELETE.
• El verbo PUT se usa normalmente para hacer UPDATE
• El verbo POST se usa normalmente para hacer CREATE.
• Las representaciones a usar se especifican mediante los llamados tipos mime. La mayoría de los tipos mime son estándares, como xml o json. El usar tipos mime estándar facilita la interoperabilidad.

La aplicación cliente típica de la web es el navegador. Los navegadores se dedican a hacer GETs sobre URIs para obtener representaciones de las distintas páginas web. En el caso habitual cada página sólo admite una representación, típicamente HTML o PDF o texto plano o imágenes. Pero eso no significa que una misma URI no pudiera soportar distintas representaciones.

Lo interesante de todo esto es que la web es un ejemplo perfecto de servicios distribuidos a nivel global totalmente interoperable (o casi). La web, y el protocolo HTTP es una arquitectura REST. La web son servicios REST que en general sólo soportan HTML. Casi cualquier página HTML es interoperable con casi cualquier navegador, y casi cualquier página HTML puede interoperar (referenciar) con otra página HTML construida por un tercero. Es sorprendente que con este claro ejemplo, presente en nuestro día a día, llegada la hora de pensar en como hacer servicios web, no se viera lo que tenemos delante de la cara, sino que se inventara algo como SOAP y WSDL. Mmmm, sospechoso.

Como veis podemos usar HTTP, URIs y tipos mime, para publicar servicios de datos, no meras páginas, que soporten multitud de representaciones y sean conformes a los principios REST. A este tipo de servicios de datos es a los que comúnmente se llaman servicios REST. Sin embargo aun tengo que contar por qué desde mi punto de vista los servicios REST son mejores que SOAP. Las razones son varias:

• HTTP es un protocolo que sigue los principios REST, por lo tanto hacer servicios REST es algo que aprovecha toda la infraestructura de la web ya existente: cache, proxies, firewall, compresión, etc. No se trata de inventar un protocolo y ver como meterlo con calzador para que encaje dentro de HTTP, sino usar el propio HTTP.
• La posibilidad de usar múltiples representaciones o formatos de datos, de forma natural, es una ventaja indiscutible. No hay que extender ningún protocolo, o limitarse a XML, el protocolo HTTP ya lo soporta de forma natural. Si usamos un poco de imaginación esto puede ser una característica muy potente.
• Los servicios REST tienen menor acoplamiento que los servicios basados en SOAP. Esto lo veremos en futuros posts.
• No necesitamos herramientas complejas, ni montones de código generado e inmantenible. Un simple framework nos basta. Para sistemas sencillos no necesitamos ni eso.
• Una aplicación AJAX o un móvil tienen la capacidad computacional suficiente para actuar como cliente de servicios REST.
• Es autodescubrible, no se necesita algo como un WSDL. Esto lo veremos también en futuros posts.

En el próximo post pienso aplicar de forma más concreta todos estos principios al mundo de las aplicaciones empresariales, y veremos como de sencillo es publicar y consumir un servicio REST. Así que ya sabéis, si queréis hacer servicios web usad los mismos principios que hicieron la web posible, usad REST.

I voted for Girls' Generation's "I Got a Boy" to win Video of the Year a...

Hacking and Security iOS

Este es un pequeño texto sobre Hackeo  y Seguridad iOS http://sdrv.ms/1fJHBRx
DESCARGAR AQUI...

Seguridad whatsapp!!!

WhatsApp y su seguridad, ¿pwn3d?

La última moda en aplicaciones móviles se llama WhatsApp, una App que cada vez se hace más popular y está redefiniendo el sistema de mensajería SMS. ¿Que qué nos ofrece? Un servicio mucho más completo, mejor y de momento gratuito.

La "pega" es que necesitamos Internet para poder comunicarnos, y que tanto emisores como receptores deben tener la aplicación, la cual funciona por ahora en iPhone, Android, BlackBerry y Nokia Symbian. Por cierto, para los usuarios de iPod Touch hay opción de utilizarla, pero tendrán que descargarla desde sitios alternativos y tener el sistema con Jailbreak, ya que en la AppStore ha desaparecido para ellos.

Pero aquí vamos a hablar de lo que nos gusta de verdad, de seguridad y, en este caso, algo de privacidad. Todas las pruebas que vamos a hacer serán de la versión 2.6.2 (la última a día de hoy) sobre un iPod Touch, en un principio el resultado no debería diferir mucho (nada) aunque cambiemos de plataforma.

Si miramos el tráfico de la red generado por la aplicación lo primero que llama la atención es que el destino del servidor es el puerto 443 (HTTPS), pero todo viaja en claro.

WhatsApp utiliza el protocolo XMPP, una potente tecnología abierta para comunicación en tiempo real.

Como mecanismo de autenticación han optado por SASL DIGEST-MD5, el cual utiliza los siguientes valores para generar el challenge (MD5):

username, password, realm, nonce, cnonce, nc, digest-uri y qop.

Todos menos el nombre de usuario y password son generados por servidor o cliente y se envían en el challenge. El nombre de usuario lo proporciona el cliente y también es enviado, y por último el password también se utiliza para generar el MD5 pero no se envía, ya que es el valor que permite que la autenticación con el servidor sea segura.

Aquí tenemos un ejemplo de challenge ya formado que es enviado por el cliente para finalizar la autenticación:

username="34666666666",

realm="s.whatsapp.net",

nonce="1438536309",

cnonce="E0487DC6-6D1A-4A67-AV70-3299TD89O29A",

nc=00000001,

qop=auth,
digest-uri="xmpp/s.whatsapp.net",

response=b98d50c159a938723d8eb8f3039afab2,

charset=utf-8

Hasta aquí todo bien, pero hay un problema: No recuerdo haber introducido ninguna password para mi cuenta durante la instalación, simplemente vinculé mi teléfono móvil. Entonces, ¿qué se está usando como password en el challenge?

Existen varias posibilidades:

- Está "hardcodeada" en el código fuente, es decir, es la misma para todo el mundo.

- Se genera en base a algún valor único del dispositivo (¿número de serie?).

- Se genera en base al username, que por cierto, es nuestro número de teléfono.

- ...

Buscando en los ficheros de configuración no encontré nada referido a la password, por lo que finalmente decidí hacer mi propia implementación de SASL DIGEST-MD5 (mención especial a este magnífico artículo) y hacer fuerza bruta a la password de un challenge generado por la aplicación.

Probé con varios diccionarios relativamente grandes y con las strings del binario de WhatsApp de iOS. No hubo resultados.

Después de probar todo lo que se me ocurrió sin obtener resultados satisfactorios decidí enviar un email a los desarrolladores con un tono de curiosidad, preguntando por la password que se usaba en la autenticación XMPP. La respuesta fue tan precisa como breve, literalmente:

password is just "password"

Pero, ¿cómo es posible? Si ésa es la password, ¿por qué no ha salido durante la fuerza bruta?

Podemos llegar a dos conclusiones:

- Ésa no es la password, y se están cubriendo las espaldas.

- Su implementación no sigue el estándar y lo han modificado ligeramente por algún motivo.

Si finalmente la password es la misma para todos los usuarios, están siguiendo una filosofía de seguridad por oscuridad que puede ser rota cualquier día. Si alguien obtiene la password que se usa, o consigue implementar el algoritmo para generar el challenge teóricamente podría iniciar sesión en el servicio con la cuenta de cualquiera, sabiendo únicamente su número de teléfono. Sería algo parecido a tener todas las cuentas de usuario sin contraseña.

La solución a ésto pasaría por hacer que el usuario introduzca una contraseña durante la instalación, o utilizar algún valor único del teléfono móvil no predecible como contraseña.

Sólo nos queda esperar a que alguien dé con la llave mágica que lo abrirá todo (si no lo han hecho aún), o que la próxima actualización de WhatsApp introduzca en el modo de autenticación una password de verdad.

Por cierto, para terminar el artículo, ¿he dicho ya que todo el tráfico de la aplicación va en claro? Mensajes, nickname, números de teléfono ...