viernes, 22 de diciembre de 2017

Capturar trazas de Fiddler de APPS en Android 7 (Nougat)

Si estamos trabajando Android versión 7 (Nougat) o superior, algunas APPS no funcionarán correctamente si intentamos capturar trazas con Fiddler, o no podremos capturar dichas trazas.
Esto es debido a un cambio implementado por el Equipo de Desarrollo de Android, que decidió que por defecto la validación de certificados HTTPS para aplicaciones con API Level 24 o posterior ignorarán todos los certificados raiz instalados por el usuario en el dispositivo. Más información en https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html

Pero no hay que desesperarse, ya que hay un workaround para poder capturar las trazas con Fiddler, el único problema es que hay que disponer del APK correspondiente a la aplicación, pero para ello tenemos la posibilidad de conseguirlo en alguna de las webs-repositorio de APPS, por ejemplo https://apkpure.com/


Aparte del APK, necesitamos tener instalado en el ordenador las siguientes herramientas para seguir este procedimiento:



Una vez que tenemos todo lo necesario, nos ponemos manos a la obra.

  • Desempaquetar el APK. 
    • Para ello abriremos una ventana de comandos como administrador en el directorio donde tengamos el APK
    • Lanzamos el siguiente comando, modificando el nombre del paquete
apktool decode app-store-release-6.3.0.apk







  •  Realizar modificaciones en el paquete.
    • Creamos un fichero llamado network_security_config.xml que estará en el directorio %nombre de la app%\res\xml
    • Editamos el fichero xml añadiendo estas líneas


<?xml version="1.0"?>
<!-- Trust preinstalled CAs -->
<certificates src="system"/>
<!-- Additionally trust user added CAs -->
<certificates src="user"/></trust-anchors></base-config></network-security-config>
    • Modificamos el fichero %nombre de la app%\AndroidManifest.xml añadiendo en la sección "application" la siguiente línea
android:networkSecurityConfig="@xml/network_security_config"









  • Empaquetar el paquete modificado.
    • Desde la ventana de comandos, entraremos en el directorio donde se ha desempaquetado anteriormente %nombre de la app%
    • Lanzaremos el siguiente comando cambiando el nombre por uno de nuestra elección que nos permita saber que es el APK modificado


apktool build -o RM_PRO_unsafe.apk









  •  Crear el certificado con el que firmaremos el APK.
    • Lanzaremos el siguiente comando (cambiando los nombres a nuestra elección), desde la carpeta donde esté instalado el Java Development Kit, en mi caso es C:\Program Files\Java\jdk1.8.0_151\bin. La ventana de comandos la abriremos como administrador.


C:\Program Files\Java\jdk1.8.0_151\bin>keytool -keystore RM_PRO_Unsafe_fix.jks -genkey -keyalg RSA -keysize 2048 -validity 365 -alias RM_PRO_Unsafe_fix
    • Le asignaremos una contraseña al certificado, y rellenaremos los datos de generación del certificado según nos los vaya solicitando.








  •  Fimar el APK
    • Copiamos el APK modificado a la carpeta donde hemos lanzado el comando anterior.
    • Lanzamos el siguiente comando haciendo referencia al certificado que hemos creado en el punto anterior y al APK modificado. Nos pedirá la contraseña del certificado.
jarsigner -keystore RM_PRO_unsafe_fix.jks RM_PRO_unsafe_fix.apk RM_PRO_unsafe_fix












  •  Re-empaquetar el APK modificado y firmado
    • Desde la ventana de comandos que teníamos abierta en el paso anterior, lanzamos el siguiente comando (la ruta de la herramienta zipalign puede cambiar dependiendo de la versión de las herramientas de desarrollo de Android que tengamos instaladas en el ordenador), modificando el nombre de salida para poder distinguirlo del APK original.
"C:\Program Files (x86)\Android\android-sdk\build-tools\25.0.3\zipalign" -f -v 4 RM_PRO_unsafe_fix.apk RM_PRO_unsafe_fix-signed.apk








 




Ya tenemos el APK de nuestra aplicación modificado para capturar trazas con Fiddler. Solo hay que instalarlo en el dispositivo Android, recordando que hay que activar la opción de seguridad que permite instalar aplicaciones desde fuentes desconocidas.



sábado, 6 de mayo de 2017

Monitorizar App Services en el Portal de Azure


Recientemente han vuelto a modificar en el Portal Ibiza de Azure las opciones para monitorizar las webapps (App Services), por lo que voy a tratar de explicar un poco las opciones que tenemos para monitorizar nuestra página web alojada en Microsoft Azure. Estas herramientas nos ayudarán a determinar el rendimiento y posibles problemas que esté sufriendo nuestro sistema.
Ahora hay que entrar desde “Diagnose and Solve Problems”.Diagnose and solve problems - app service - azure


Nada más abrir esa opción podemos ver una gráfica con el status de las últimas 24h  y podemos intercambiar entre Availability, Requests y Performance.


Diagnose and solve problems - app service - azure

Diagnose and solve problems - app service - azure

Diagnose and solve problems - app service - azure





También hay una zona con Herramientas útiles para diagnosticar el estado del WebApp. Voy a intentar explicar un poco cada una de ellas:
Diagnose and solve problems - app service - azure


  • Metrics per instance (Apps):

En esta sección podemos revisar múltiples contadores de rendimiento (.NET Process, ASP.NET, .NET CLR, TCPv4 y TCPv6) y en distintos intervalos de tiempo, viendo las mismas en todas las instancias a la vez o indicando manualmente que instancia queremos comprobar.

Diagnose and solve problems - app service - azure


También podemos ver las métricas del site, viendo las mismas en todas las instancias a la vez o indicando manualmente que instancia queremos monitorizar.

Diagnose and solve problems - app service - azure


  • Metrics per instance (App Service Plan)
Aquí podemos ver las métricas de las instancias del Service Plan, viendo todas las APPS que comparten dichas instancias al estar en el mismo Service Plan, permitiendo ver también las métricas de los slots de staging. Podemos filtrar por instancia, intervalo de tiempo y Sites.

Diagnose and solve problems - app service - azure
Diagnose and solve problems - app service - azure

Diagnose and solve problems - app service - azure



  • Live HTTP Traffic

Como su nombre indica, podemos visualizar el tráfico recibido por el WebApp en tiempo real, viendo las peticiones correctas, así como los errores de servidor (5xx) y las peticiones erróneas (4xx)

Diagnose and solve problems - app service - azure



  • Application Events

Es un Visor de Eventos del IIS donde está alojado el WebApp.


Diagnose and solve problems - app service - azure


  • Failed Requests Tracing Logs (FREB)

Esta herramienta realiza un seguimiento basado en una solicitud y produce un archivo de registro (en formato .xml) que muestra eventos y notificaciones de los diversos módulos que trabajaron en la solicitud durante su ciclo de vida.
Se puede filtrar por la URL, por el tipo de petición, por la hora y fecha, por el código de estatus…

Diagnose and solve problems - app service - azure
Diagnose and solve problems - app service - azure


  • Diagnostics as a Service

Permite lanzar una solicitud para recopilar información en forma de log y analizada en formato HTML del Visor de Eventos, de los logs HTTP y hacer un Memory Dump (utilizar el Memory Dump con cuidado, ya que puede provocar una caída del servicio) de la instancia.

Diagnose and solve problems - app service - azure


  • Mitigate

Permite crear reglas de auto-reciclado del WebApp basado en el número de peticiones en un determinado intervalo de tiempo.

Diagnose and solve problems - app service - azure

Diagnose and solve problems - app service - azure





  • Advanced Application Restart

El reinicio avanzado de aplicación le permite reiniciar instancias individuales de la aplicación y reiniciar de forma inteligente varias instancias. El temporizador de reinicio le permite especificar el intervalo de tiempo en segundos que se usa al reiniciar determinadas instancias de la aplicación y reducir el efecto de los arranques en frío.

Diagnose and solve problems - app service - azure


miércoles, 23 de noviembre de 2016

WhatsApp Web se integra con Giphy

Seguramente todos estáis al tanto de que el famoso servicio de mensajería WhatsApp lleva unos meses permitiendo compartir GIFs animados.

En la versión para iOS ya permite hacer búsqueda de GIFs en la famosa base de datos de imágenes http://giphy.com.

Desde la plataforma Android aún no contamos con esa característica, pero si como yo eres de los que usa la versión web de WhatsApp https://web.whatsapp.com, tal vez te interese saber que ya se pueden hacer búsquedas de GIFs animados para adjuntar a tus conversaciones.

Para ello, estando dentro de una conversación, pulsamos el icono que está a la izquierda de la ventana donde escribimos los mensajes, que es la carita que nos permite añadir los iconos.




En la parte superior de la sección que se despliega, está la barra con las distintas opciones de iconos que podemos compartir. A la derecha del todo tenemos un icono que pone GIF, pulsamos en él.



En la ventana de texto que nos aparece justo encima de la primera muestra de GIFs que nos ofrece la base de datos, podemos introducir alguna palabra o combinación de palabras relacionadas con lo que queremos buscar.


Podremos desplazarnos por las distintas imágenes para seleccionar la que queramos compartir, y pulsar sobre ella. Nos presentará una vista previa a la vez q permitirá introducir algún comentario.



Y ya sólo nos hace falta darle a la flecha de enviar para compartir el GIF en la conversación.


miércoles, 9 de diciembre de 2015

Azure SQL Geo-Replication Change Role Procedure (UPDATE)

In this entry Azure SQL Geo-Replication Change Role Procedure I explained how to proceed in a Azure SQL disaster whit the Geo-Replication active.

Well, this procedure has changed. Now there is a new and simplier way to initiate a DataBase failover in the Azure Ibiza Portal.

Browse to SQL Databases and select the Primary Database.


Browse to All Settings and then to Geo-Replication


Select the Secondary DataBase and clic on the FailOver option in the next slide.


Accept in the next prompt if you are sure you want to change the order of the DataBase (if we are in a critical situation, we are sure of that)


The DataBases status will change to Pending for a while.



We only have to wait until the FailOver ends and we will have the order of our DataBases changed.



The main advantage of this procedure is that we don´t lost the Geo-Replicaton configuration and we can switch between the DataBases all the times we need (but it is better not to need it ever)




miércoles, 21 de octubre de 2015

Azure SQL Geo-Replication Change Role Procedure

In the case of one Azure SQL Database gets degraded, if we have configured the Geo-Replication as shown in this post Azure SQL Geo-Replication Configuration, we can change the role of the replicated DB with this procedure and use it as the main DB.

1.  For activating the Secondary DB of the Geo-Replication, go to SQL databases in Ibiza Portal.


     2. Open the Primary DB and go to Geo-Replication

  
       3. On the Secondary DB, clic the 3 points on the right and select Stop Now



      4. One message appears indicating that the replication will stop and the Secondary DB will be converted in a stand-alone DB, press YES




      5. Using the command Get-AzureSqlDatabaseCopy we can verify the non-replicated status of the DB, it must not return any information.



Azure SQL Geo-Replication Configuration


We can use the Azure SQL Geo-Replication feature as DB disaster recovery plan. We make a copy any DB in another Azure Region.

1. For activating DB Geo-Replication, go to SQL databases in Ibiza Portal.



2. Select the DB > All Settings > Geo-Replication



3. Choose the Target Region where the DB will be replicated (the best option is to select the recommended one)


4. Create a new DB server filling the name of the server, the admin and the password. Select to create V12 server, and check the option to allow Azure services to access server, and press OK.


5. After the creation of the new server, in the “Create secondary” slide appears the new created server. In the lower left corner, press CREATE.


6. In the Geo-Replication slide appears the new Secondary server initializing.



7. When the process is finished, the status of the new replication DB appears as Non-Readable.


8. Now there are two DB with the same name in two different servers, each one in one Location.



9. In the configuration of both DB, appears the corresponding Geo-Replication role.




10. To verify the status of the copy between both DB, use the command Get-AzureSqlDatabaseCopy


11. Now that we have configured the Geo-Replication, in disaster case we can activate the replicated DB following the instructions in this post Azure SQL Geo-Replication Change Role Procedure