Versión 1.0 de las herramientas de Apache Cordova de Microsoft

El pasado día 1 de octubre el equipo de ingeniería de Visual Studio anunció la disponibilidad definitiva de la versión 1.0.0 de las herramientas para Apache Cordova, conocidas como TACO (Tools for Apache Cordova).

Apache Cordova es una suite de herramientas de código abierto que permiten crear aplicaciones móviles nativas basadas en HTML5. De este modo podemos aprovechar lo que ya sabemos de desarrollo web y, sin necesidad de aprender nuevosframeworks o lenguajes, pudiendo además acceder a las APIs nativas desde JavaScript. Son una gran opción para muchos desarrolladores. Más información.

La disponibilidad de TACO v1.0.0.0 es una gran noticia. Estas herramientas facilitan mucho la vida a los programadores de Apache Cordova que trabajan desde Windows o Mac.

TACO es un conjunto de herramientas de líneas de comando y documentación que se sitúan por encima de las herramientas de Cordova para facilitar la instalación y el trabajo con el producto. Son 100% compatibles con las herramientas CLI de Cordova, por lo que si ya las estás utilizando, con TACO estarás como en casa.

Básicamente nos facilitan:

• La creación de proyectos y entornos de trabajo para Cordova. Los proyectos de Apache Cordova se basan mucho en ciertas plataformas y plugins para poder funcionar. Cuando cambias de versión, en teoría, la cosa es muy sencilla. En la práctica puede ser una pesadilla. Mediante los Kits de TACO puedes crear en un instante entornos de desarrollo validados para funcionar con una determinada versión de Cordova, con las plataformas, herramientas de build y plug-ins apropiados. Es especialmente interesante para principiantes que quieren ir a través de la línea de comandos.
• Asistencia durante el desarrollo: nuevamente muy útil para principiantes. A medida que vas quemando etapas en el desarrollo, TACO te va sugiriendo los siguientes pasos que debieras dar, así como buenas prácticas. De este modo no te perderás y además te ayudará a crear aplicaciones más robustas.
• Control de dependencias: otro punto conflictivo de Cordova es tener bien instaladas todas las dependencias que necesitamos para hacer funcionar las aplicaciones. TACO proporciona un comando taco install-reqs que instala todos los paquetes necesarios y nos simplifica la vida.
• Compilar y probar: permite compilar las aplicaciones para diversas plataformas, incluyendo iOS desde Windows, para lo cual se conecta remotamente a la máquina con OS X que va a compilar. También permite depurar remotamente.

Si además trabajamos en Windows podemos instalar Visual Studio 2015 Community Edition (gratuito) que incluye lasherramientas visuales para Apache Cordova. Éstas nos facilitan todavía más el desarrollo ofreciéndonos herramientas visuales, asistencia de escritura de código, prueba en dispositivos reales o emuladores, depuración y análisis locales y remotos, compilación remota para iOS usando equipos con Mac propios en la nube...

A continuación tienes toda la información:

• TACO CLI
• Visual Studio TACO
• Página en GitHub con el código de TACO CLI
• Documentación de TACO CLI
• Documentación de VS TACO

Fuente: http://www.campusmvp.es/recursos/post/Version-10-de-las-herramientas-de-Apache-Cordoba-de-Microsoft.aspx

CustomErrors en .NET: Cómo evitar fugas de información por los mensajes de error

 Para terminar este ciclo que he dedicado a los errores, o más concretamente a los mensajes de error, en aplicaciones .NET, es obligatorio terminar hablando de la posibilidad que permite el framework de personalizar, a nivel de servidor en el fichero Machine.Config o a nivel de aplicación en Web.Config, los mensajes de error que se van a mostrar. Ya hemos visto que los mensajes de error en modo Debug pueden generar un problema de seguridad grande al mostrarse el código fuente de la aplicación, pero los mismos mensajes de error .NET, aún no estando activado dicho modo, pueden seguir dando muchos detalles de la plataforma a los posibles atacantes. Esto se puede solucionar con una personalización robusta de los mensajes de error.

Figura 1: CustomErrors en aplicaciones .NET

La configuración de los mensajes de error permite que se personalice el entorno con cuatro posibilidades distintas, que deben ser tomadas en cuenta para cada necesidad. Esto se hace dentro de la sección de Machine.Config o Web.Config dedicado a System.Web, tal y como se ve a continuación:

<system.web>

<customErrors mode="On|Off|RemoteOnly" defaultRedirect="~/Error/Index" />

</ system.web>

CustomErrors mode OFF

Si el framework tiene configurado el valor de CustomErrors a OFF, eso quiere decir que se deben mostrar los errores .NET detallados, con la información concreta de qué excepción no controlada lo ha generado.

Figura 2: Error detallado que se obtiene con CustomErrors OFF

Un atacante podrá saber en todo momento qué es lo que está fallando en la aplicación .NET y le servirá para preparar una estrategia de ataque mucho más fácilmente.

CustomErrors mode ON

En este caso, cuando se genere un mensaje de error se mostrará una información genérica. Estos mensajes son los famosos Runtime Error que tantas veces aparecen en aplicaciones .NET. Esto indica que hay una excepción no controlada, pero el código del mensaje no da detalles sobre qué lo ha generado.

CustomErrors mode RemoteOnly

En este caso, el mensaje de error será también el genérico "Runtime Error" cuando se esté conectado el cliente desde una ubicación remota, y detallado cuando se genere desde la máquina local. En el siguiente ejemplo se puede ver como el mensaje indica que es genérico, pero que sería detallado si la conexión fuera local.

Figura 3: Error genérico que se obtiene con CustomErrors ON o
con CustomErrors RemoteOnly en una conexión remota

CustomErrors mode ON | RemoteOnly con DefaultRedirect

En el caso de que se haya decidido poner un modo de CustomErrors configurado a ON o a RemoteOnly, se puede configurar una página de error genérica. Esto haría que se diera solo la información corporativa que se desease. En el siguiente ejemplo el DefaultRedirect de Microsoft.com con los errores .NET.

Figura 4: Excepción controlada con CustomErrors y DefaultRedirect

Otros Errores de IIS y/o de Request Filtering

Hay que tener presente que, en un servidor IIS con una aplicación .NET hay otros mensajes de error que también hay que configurar. Ya vimos hace poco que los mensajes de error del módulo de Request Filtering son totalmente distintos, o los que se obtienen por cualquier excepción en el propio servidor IIS.

Figura 5: Mensaje de error 405 en un servidor IIS

Pero también serán distintos los errores del propio servidor IIS que tengan que ver con aplicaciones que no sean .NET, como en el caso de aplicaciones ASP normales, tal y como puede verse en la siguiente imagen.

Figura 6: Mensaje Error 404 en un servidor IIS con una aplicación ASP

Es decir, configurar CustomErrors en .NET ayuda a tener los errores del framework .NET controlados, pero debes controlar los mensajes de error de todos los frameworks, que puedes tener las fugas de información en cualquier sitio.

Saludos Malignos!

Fuente: http://www.elladodelmal.com/2015/06/customerrores-en-net-como-evitar-fugas.html

Integrar aplicacion de google maps con c#

Buenas.

Algunas referencias buenas para integración:

http://www.aspsnippets.com/DownloadFile.aspx?File=cac17c4c-fafd-42ac-90c0-6c91c5c83065.zip#center   --Ejemplo

http://www.aspsnippets.com/Articles/Google-Maps-GeoLocation-API-Example.aspx  --Ejemplo online

http://www.codeproject.com/Articles/291499/Google-Maps-API-V-for-ASP-NET --frame

https://stackoverflow.com/questions/20372464/using-google-map-geolocation-api-service-in-asp-net-c-sharp

http://www.esasp.net/2009/10/google-maps-para-aspnet.html  --Ejemplo en español