Cambiar el explorador predeterminado en Visual Studio 2010

17. March 2011 17:10 by Oscar.SS in Desarrollo Web, Herramientas  //  Tags: , ,   //   Comments (0)

Si no recuerdo mal, desde la versión 2005 de Visual Studio, cuando trabajabamos en proyectos WebForms siempre hemos podido cambiar el explorador por defecto cuando ejecutabamos nuestra aplicación.

Visual Studio 2010 no iba a ser menos y también nos permite cambiar el explorador que se lanzará cuando ejecutemos nuestro proyecto web con ASP.NET. Para realizar este cambio, procederemos exactamente igual que en las versiones anteriores de Visual Studio.

Abrimos en el editor de código una página aspx y en el menú navegamos hasta File -> Browse With.

 

 

Es importante mencionar, que esta opción solo estará disponible si tenemos abierta una página aspx en el editor de código fuente.

 

A continuación se nos abrirá la ventana de administración donde podremos añadir cuantos exploradores necesitemos y establecer por defecto el que más nos convenga en cada caso.

 

 

¿Pero que pasa con los proyectos ASP.NET MVC?

 

Lamentablemente esta funcionalidad no viene de serie en Visual Studio 2010 para proyectos MVC, ni para las vistas WebForm, ni para el motor de vistas Razor de la versión MVC 3. Pero todo tiene solución gracias a un plugin gratuito que podemos descargar desde la galería de Visual Studio haciendo click en la siguiente imagen.

 

 

Solo es necesario descargarlo, instalarlo y reiniciar Visual Studio. Ahora solo nos queda añadir esta herramienta a las barras de menú de Visual Studio (View -> Toolbars -> Detault Browser Switcher).

 

 

Podemos comprobar que se ha añadido esta herramienta en una de las barras, desde la que podemos elegir el explorador predeterminado para la ejecución del proyecto.

 

 

Por defecto incluye para elegir entre los 5 exploradores más comunes, IE, FireFox, Chrome, Safari y Opera. Pero el plugin también permite añadir nuevos exploradores y en general personalizar esta herramienta.

 

 

Como curiosidad comentar que en un proyecto ASP.NET MVC con el motor de vistas Razor solamente podremos establecer el explorador para la ejecución desde la barra de herramientas. En cambio, para el motor de vistas WebForm tendremos acceso a esta funcionalidad no solo desde la barra de herramientas, también desde le menú File o desde el explorador del proyecto con el botón secundario sobre una vista aspx, tal y como muestran las imágenes siguientes.

 

Curso de ASP.NET MVC 3

10. March 2011 18:45 by Oscar.SS in Formación, Personal  //  Tags: , ,   //   Comments (4)

Normalmente cuando realizo un curso de formación no tengo por constumbre comentar nada al respecto en este blog (no así con los libros),  pero en este caso voy hacer una leve excepción porque la ocasión realmente lo merece.

Recientemente he terminado el temario completo del curso "Desarrollo Web con ASP.NET MVC 3" de la buena gente de Campus MVP. Sinceramente puedo decir que es el curso con el que más he disfrutado de todos lo que he realizado nunca. Aunque a más de uno, los vocablos disfutar y formación les cuestes imaginarlo en la misma frase.

 

 

Para los que venimos de los automatismos que nos brinda ASP.NET Web Forms, adentrarse en las maravillas del patrón MVC puede resultar chocante en primera instancia. Se puede pensar, no sin razón, que existe cierto aumento en la curva de aprendizaje. Esto, que podría resultar un problema a la hora de lanzarse a por esta tecnología, o esta forma de trabajar, lo han resuelto satisfactoriamente con la estructura de los contenidos del curso. Poco a poco (algo más lento para los torpes como yo), y con una acertada organización de los conceptos, te adentras en las maravillas del patrón MVC y de la última versión del framework ASP.NET MVC.

Quizás otra de las preguntas que nos hacemos, y posiblemente la más importante y dificil de solventar al principio, es si un curso merece la inversión económica que vamos a realizar. Es decir, ¿es realmente lo que necesito para mis objetivos?. Esta es una pregunta muy subjetiva que evidentemente su respuesta esta sujeta a los objetivos particulares de cada uno. Pero os puedo asegurar, que si vuesto objetivo es tener los conocimientos y herramientas necesarias para desarrollar aplicaciones profesionalmente con esta tecnología, el curso cumple con esto y mucho más. Realmente os diferenciaréis profesionalmente del resto de vuestros compañeros de trabajo.

Sin duda alguna otra de las ventajas que tiene este curso es su tutor. José María Aguilar es un aténtico crack. Si realizáis este curso, o cualquier otro donde sea, os recomiendo siempre que preguntéis y preguntéis hasta  hartaros. Claro que para preguntar hay que profundizar primero. No cabe duda, que tener un tutor con el nivel de José María, es un valor añadido a la formación, pero solo si lo utilizáis. ¡Así que a preguntar que para eso están!

Seguridad de directorios en ASP.NET

6. March 2011 08:43 by Oscar.SS in Desarrollo Web  //  Tags: ,   //   Comments (10)

Practicamente en la totalidad de nuestras aplicaciones web debemos implementar la seguridad de usuarios para determininar cuales de estos tienen permisos a determinados recursos. Cuando la seguridad sea muy complicada, con multitud de niveles y sobre multitud de recursos, recuriremos a la seguridad basada en perfiles o roles almacenados en una base de datos.

Sin embargo, para contextos de seguridad mucho más simples, podemos usar la seguridad basada en establecer ciertos directorios o elementos como privados y definir unos pocos permisos en el web.config. Por ejemplo, un blog como este, en el que todas las páginas son públicas a todos los usuarios, excepto las encargadas de administrar y editar los artículos que solo serán accesibles al administrador del blog.

En casos tan sencillos como este, basaremos la seguridad mediante formularios, directorios (o elementos) privados, y la definición de permisos de usuarios en el web.config.

Supongamos que estamos desarrollando una aplicación web en el que todas sus páginas serán públicas. El contenido de estas páginas es dinámico y se edita por medio de un back office al que solo podrán acceder los administradores del sitio web. Veamos como hacerlo.

 

Definir directorios privados

En primer lugar, definimos en el web.config que directorios o elementos serán privados y cuales serán públicos. Cuando hablamos de directorios, nos referimos naturalmente a una carpeta (y todo su contenido) de nuestro proyecto. Y cuando hablamos de elementos, nos referimos por ejemplo, a ciertas páginas.

 

 

Mediante la sección <location> del web.config establecemos el directorio BackOffice como privado a todos los usuarios no autentificados.

 

<configuration>
    
<system.web>
        
<!--...-->
    
</system.web>
    
<!--Marcamos el directorio BackOffice como privado-->
    
<location path="BackOffice">
        
<system.web>
            
<authorization>
                
<deny users="?"/>
            
</authorization>
        
</system.web>
    
</location>
    
<!--...............................................-->
</configuration> 

 

Sobre la sección <location> debemos tener hacer varios apuntes:

1- Esta sección se encuentra fuera del elemento <system.web> aunque en su interior tiene una sección hija con el mismo nombre.

2- Podemos tener tantas secciones <location> como necesitemos.

3- El atributo path="" de nuestro ejemplo apunta a un directorio, pero perfectamente prodía apuntar a una sola página path="BackOffice/AdmNoticias.aspx".

4- Mediante la sección <deny users="?" /> denagamos el acceso a todos los usuarios anónimos, es decir, no autentificados. Pero también existe otra posibilidad <allow users="*" /> que da acceso a todos los usuarios ya estén autentificados o no. Con la combinación de ambos elementos estableceremos la privacidad o publicidad de nuestros recursos.

 

Autentificacion mediante formularios

Una vez establecidos, en nuestro sitio web, que recursos serán públicos y cuales privados, definimos en el web.config que la autentificación se realizará mediante formulario.

 

<configuration>
    
<system.web>
        
<!--Establecemos la configuracion de atentificacion-->
        
<authentication mode="Forms">
            
<forms loginUrl="Login.aspx">
                
<credentials passwordFormat="SHA1">
                    
<user name="administrador1" password="C46D4FJ43L6KJ424355403CCE60B85421E5E6FB62"/>
                    <
user name="administrador2" password="56J35K6J353KLL56P635KJ33L6KJ424356980MRMG"/>
                </
credentials>
            
</forms>
        
</authentication>
        
<!--...............................................-->
    
</system.web>
</configuration> 

 

En primer lugar definimos el atributo mode="Forms" indicando que la autentificación se realizará mediante formulario. En el atributo loginUrl="" indicamos la ruta en nuestro proyecto donde se encontrará el formulario de login donde los usuarios tendrán que autentificarse. Será ASP.NET quién se encarge de redirigir automaticamente a los usuarios a este formulario cuando se intente un acceso a un recurso protegido.

 

 

Mediante la sección de credenciales definimos que estás estarán codificadas mediante el algoritmo SHA1. Tan solo es una forma de proteger las contraseñas de los usuarios para que no estén estricas literalmente en el web.config o para evitar su visibilidad si la solicitud es "leida" por usuarios maliciosos.

A continuación mediante la sección <user> definimos las credenciales de los usuarios (nombre y contraseña) que tendrán acceso a los recursos privados. Ahora veremos como generar estos valores hash de codificación.

 

Generar valores hash

Para generar los valores hash de las contraseñas hacemos lo siguiente.

string claveHash System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile("contraseñaUsuario""SHA1");

Al ejecutar este código, el valor de la variable claveHash contendrá la codificación SHA1 de la contraseña del usuario. Solo tendremos que copiarla y pegarla en la sección correspondiente del web.config. Naturalmente este proceso de copiar y pegar a mano en el web.config las contraseñas codificadas es poco ortodoxo, pero como ya comentamos anteriormente, estamos hablando de un contexto de seguridad donde tenemos muy pocos usuarios con credenciales. Si tuvieramos 100 usuarios con distintos roles, sería inmantenible realizarlo por este sistema en lugar de almacenarlos en una base de datos.

 

Validación de usuarios

Cuando los usuarios introducen en el formulario anterior sus credenciales (nombre y contraseña)...¿como los validamos contra las credenciales definidas en el web.config?

 

    protected void ibLogin_Click(object sender, System.Web.UI.ImageClickEventArgs e)
    {
        
if (System.Web.Security.FormsAuthentication.Authenticate(txUsuario.Value, txPassword.Value))
            System.Web.Security.FormsAuthentication.RedirectFromLoginPage(txUsuario.Value, 
false);
        else
            
spError.InnerText "Usted no está autorizado para entrar a este sitio";
    
}

 

En primer lugar, comprobamos si las credenciales escritas en el formulario por el usuario corresponden con algunas de las que hemos defnimos anteriormente en el web.config. En caso afirmativo, redirigimos al usuario al recurso al que estaba intentando acceder.

De esta redirección se ocupa por nosotros ASP.NET. Funciona de la siguiente manera. Cuando nosotros intentamos acceder a un recurso protegido mediante una petición,

- GET //www.misitio.com/BackOffice/AdmNoticias.aspx

ASP.NET nos redirige automaticamente al recurso que hemos establecido como login en el web.config de la siguiente forma.

- GET //www.misitio.com/Login.aspx?ReturnUrl=/BackOffice/AdmNoticias.aspx

Como se puede apreciar en la url anterior, ASP.NET se encargará, mediante el parámetro de QueryString ReturnUrl una vez verificadas las credenciales del usuario, de enviarnos al recurso al que intentabamos acceder.

Recent Comments

Comment RSS

Month List