.net - tutorial - clickonce vb net 2010
¿Despliegue de ClickOnce de.NET protegido con contraseña? (4)
No estoy seguro de que se pueda hacer. Puedo estar equivocado, pero no pensé que eso funcionaría. Además de cualquier otra cosa, incluso si el usuario ingresa sus credenciales para obtener la aplicación .a, el tiempo de ejecución realiza una descarga por separado, para lo cual necesita acceso anónimo.
Si desea proteger tanto al cliente, es posible que tenga que idear una forma diferente de implementarlo.
¿Cómo puedo proteger una aplicación implementada ClickOnce con una contraseña ? ¿Tengo que cambiar la configuración de IIS de la web o hay alguna forma de hacerlo programáticamente? Estoy usando Visual Studio 2005 (.NET 2.0).
Si tengo que usar credenciales web, ¿las actualizaciones automáticas de la aplicación aún son posibles?
Sería genial si pudiera proporcionar algún código de muestra o instrucciones detalladas para administrar IIS.
¡Gracias!
Un instalador ClickOnce es solo un par de archivos instaladores que se sientan en su servidor web, ¿verdad? Entonces, puedes implementar algún tipo de seguridad de directorio en esos archivos. Puedes hacer esto en un par de niveles diferentes, creo; por ejemplo, permisos IIS o (si sus usuarios están en su dominio) permisos NTFS.
Además, los permisos de IIS (¿todo en realidad?) Deberían poder configurarse programáticamente.
Encontré una solución posible en este artículo de MSDN: Implementación y seguridad de ClickOnce .
Autenticación basada en formularios ASP.NET
Si desea controlar a qué implementaciones puede acceder cada usuario, no debe habilitar el acceso anónimo a las aplicaciones ClickOnce implementadas en un servidor web. Más bien, permitiría a los usuarios acceder a las implementaciones que haya instalado en función de la identidad de un usuario (utilizando la autenticación de Windows NT).
Si se implementa en un entorno sin autenticación de Windows NT, una solución podría ser intentar usar la autenticación ASP.NET basada en formularios para autenticar al usuario. Sin embargo, ClickOnce no admite la autenticación basada en formularios porque usa cookies persistentes; estos presentan un riesgo de seguridad porque residen en el caché de Internet Explorer y pueden ser pirateados. Por lo tanto, si está implementando aplicaciones ClickOnce, no se admite ningún escenario de autenticación además de la autenticación de Windows NT.
Pasar argumentos
Una consideración de seguridad adicional ocurre si tiene que pasar argumentos a una aplicación ClickOnce. ClickOnce permite a los desarrolladores suministrar una cadena de consulta a las aplicaciones implementadas en la Web. La cadena de consulta adopta la forma de una serie de pares de nombre-valor al final de la URL utilizada para iniciar la aplicación:
http://servername.adatum.com/WindowsApp1.application?username=joeuser
Por defecto, los argumentos de la cadena de consulta están deshabilitados. Para habilitarlos, el atributo trustUrlParameters se debe establecer en el manifiesto de implementación de la aplicación . Este valor se puede establecer desde Visual Studio y desde MageUI.exe. Para conocer los pasos detallados sobre cómo habilitar pasar cadenas de consulta, consulte Cómo recuperar información de cadena de consulta en una aplicación ClickOnce.
Nunca debe pasar los argumentos recuperados a través de una cadena de consulta a una base de datos o a la línea de comandos sin verificar los argumentos para asegurarse de que son seguros. Los argumentos inseguros son los que incluyen bases de datos o caracteres de escape de línea de comandos que podrían permitir que un usuario malintencionado manipule su aplicación para ejecutar comandos arbitrarios.
Nota: los argumentos de cadena de consulta son la única forma de pasar argumentos a una aplicación ClickOnce al inicio. No puede pasar argumentos a una aplicación ClickOnce desde la línea de comando.
La única solución que he visto está aquí: haga clic en Autorizaciones de una sola vez
Nos hemos encontrado con el mismo problema al intentar asegurar una aplicación. El único problema con la solución anterior que he notado es que la información de la cookie está en la URL, lo que significa que si alguien teóricamente interceptara la URL, podrían usarla para descargar también la aplicación. Aparte de eso, parece una solución viable.