Menú principal

lunes, 12 de noviembre de 2012

iOS inter-app communication methods: URL schemes

La mayoría de desarrolladores iOS saben que Apple confina las apps de terceros en sus sandboxes como medida de seguridad y conocen cuáles son los métodos de comunicación entre procesos, más conocido como IPC (Inter Process Communication) o también Inter-App Communication. Este mecanismo se basa en el manejo de esquemas URL personalizados (Custom URL Schemes). El primer paso es registrar el esquema URL deseado en el fichero Info.plist, tal y como se muestra en la siguiente captura de un ejercicio de ejemplo:

Figura 1: Registrando el esquema URL deseado para una app

Una vez hecho esto, hay que declarar el método application:handleOpenURL, para poder manejar las peticiones URL, tal y como se muestra en el siguiente ejemplo de código:

Figura 2: Ejemplo de código para manejar peticiones URL

Este método es el encargado de recoger las peticiones URL, que cumplan con el esquema declarado en el fichero Info.plist. Es decir, si nos encontramos en Safari, y se escribe la siguiente petición URL, tal y como se aprecia en la siguientes capturas, se pasarían datos a la aplicación, que tenga declarado el esquema URL “i64URL”.

Figura 3: Escribiendo una petición URL en Safari

Y, acorde al ejemplo de código mostrado, en el que se presenta una alerta con los datos recibidos en la petición URL, se presenta la captura de lo que ocurre:

Figura 4: App recibiendo datos a través de una petición URL

Hasta aquí todo bien. Pero hay que tener en cuenta varias cosillas en cuanto a seguridad. La primera es, que este método va a ser "deprecado" en cualquier momento, con lo que desde ya conviene utilizar el siguiente método:
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
La ventaja de utilizar este método es que permite validar la aplicación de origen que instanció la petición URL. Además se podría especificar, que sólo determinadas apps puedan invocar a nuestra app. A continuación, se presenta un ejemplo, en el que se autoriza sólo a Safari:

Figura 5: Ejemplo de código autorizando a Safari para realizar peticiones URL a nuestra app

Otro concepto básico en cuanto a seguridad sería aplicar unos buenos filtros de validación de los datos recibidos a través de la petición URL, antes de que ésta sea procesada. En el código de ejemplo, se muestra un filtro por longitud de la petición - extraído del ejemplo LaunchMe de la sección SampleCode de Apple Developer -, pero evidentemente habrá que aplicar una expresión regular o un filtro personalizado según la criticidad de los datos pasados, o según aplicación. Hay muchas aplicaciones que utilizan este sistema, como por ejemplo Credit Card Terminal:

Figura 6: Web de Innerfence presentando su app Credit Card Terminal

La compañía declara, que por temas de seguridad, utiliza APIs licenciadas por el MIT, que seguramente hagan las cosas bien aunque, como siempre, habría que hacer una auditoría de la app, debido a la criticidad de sus datos. Un ejemplo de de petición URL de esta app:

Figura 7: Petición URL de la app de Innerfence

Innerfence tiene publicada la API para que los desarrolladores puedan integrar Credit Card Terminal en sus apps. Si se descarga, se puede ver el código, y por ejemplo, como aplican sus expresiones regulares:

Figura 8: Expresiones regulares para filtrar datos recibidos en peticiones de URL

Por último cabe comentar un detalle, no de seguridad, sino en cuanto a usabilidad, y que comenta Innerfence en su blog. Es habitual, encontrar muchas apps que utilizan el sistema de esquemas URL, y en la mayoría de los casos, cuando desde una aplicación se lanza otra, el usuario se queda “aislado” en la otra aplicación, teniendo esto un pequeño impacto negativo, en la experiencia de usuario.

Lo ideal es que cuando una app lance a otra, una vez se haya terminado la tarea, desde la app destino, se pueda volver a la app inicial, y en el punto en que el usuario se encontraba. Para ello, Innerfence envía en la petición URL, una URL de retorno - tal como se aprecia en la figura 7 -, indicando con un parámetro, en este caso llamado record_id, a que punto de la app debe regresar. Dicha información, puede ser utilizada por la app destino, para poder realizar una nueva petición URL a la app inicial, y que le proporciona al usuario un plus en su experiencia con la app. A continuación, la petición URL, que haría la app destino, para regresar a la app origen:

Figura 9: Petición URL para volver a la app origen

Como conclusión, se va a recapitular los puntos principales de los URL schemes:
- Hay que tener mucho cuidado al utilizarlos. No siendo conveniente utilizarlos para pasar datos sensibles o críticos, ni contraseñas - ya que para eso hay otros métodos, como el keychain -.
- No deben utilizarse para realizar cambios en las configuraciones.
Hay que utilizar el método no deprecado, que además permite validar el origen de las invocaciones.
- Es muy importante realizar una validación exhaustiva, de los datos recibidos a través de las peticiones URL, antes de que estos sean procesados.
- Tener cuidado a la hora de declarar el esquema URL, ya que si es igual al de otra app, el comportamiento es impredecible.
Si deseas más información, puedes leer el libro de Desarrollo de aplicaciones iOS para iPhone & iPad, consultar la Apple URL Scheme Reference, o la siguiente Wiki. Si quieres aprender a programar dispositivos iOS en la web de Informática64 publicaremos las próximas convocatorias del Curso de Desarrollo de aplicaciones para iOS.

No hay comentarios:

Publicar un comentario

Entrada destacada

Proteger tu cuenta de Google y de Gmail con Latch Cloud TOTP #Latch #Gmail #Google

La semana pasada se liberó la nueva versión de Latch y nuestro compañero Chema Alonso hizo un repaso de todo ello en su artículo Latch...

Otras historias relacionadas

Entradas populares