Esta es la primera parte de una serie de dos. El planteamiento es crear un programa que replique la funcionalidad básica de "RunAs", la utilidad de línea de comandos que permite ejecutar cualquier programa suplantando a otro usuario. Nuestro particular RunAs se encargará de solicitarnos de forma segura la clave para el usuario indicado y luego lanzará el .exe indicado suplantando al mismo y por lo tanto permitiéndonos hacer una escalada de privilegios o, por el contrario, ejecutar un programa con menos privilegios que el usuario actualmente autenticado en el sistema.

Su uso básico es este:

runas usuario ejecutable.exe

o bien

runas dominio\usuario ejecutable.exe

si queremos indicar el dominio también.

En este primer post voy a mostrar lo más sencillo que es lanzar el proceso suplantando a un usuario. Dejaré para el próximo la obtención de la clave del usuario y su almacenamiento seguro y pondré el código completo para descarga.

El código principal del programa es el que muestro a continuación y que ahroa explicaré:

public static void Main(string[] args)
        {
            if (args.Length != 2)
            {
                MuestraUso();
                return;
            }

            //Nombre de usuario a suplantar
            string usuario = args[0];
            string[] partes = usuario.Split('\\');

            SecureString claveSegura = PideClave(usuario);

            //Si no han introducido han pulsado ESC salimos sin hacer nada.
            if (claveSegura == null)
                return;

            //Programa a ejecutar
            string programa = args[1];

            try
            {
                ProcessStartInfo psi = new ProcessStartInfo(programa);
                psi.UseShellExecute = false;

                if (partes.Length == 2)
                {
                    psi.Domain = partes[0];
                    psi.UserName = partes[1];
                }
                else
                {
                    psi.UserName = partes[0];
                }

                psi.Password = claveSegura;

                Process.Start(psi);
            }
            catch (Win32Exception e)
            {
                Console.WriteLine("Se ha producido un error ejecutando la aplicación:");
                Console.WriteLine(e.Message);
            }

Si no se introducen dos argumentos en la línea de comandos se usa el método MuestraUso que muestra por pantalla la ayuda del programa (no lo voy a poner aquí pues es trivial). Para poder depurar el programa deberemos introducir unos parámetros de ejemplo en la pestaña "Debug" de las propiedades del proyecto:

En el primer parámetro se espera el nombre de usuario, el cual puede estar formado (o no) por dos partes: el dominio y el nombre de usuario separado por una barra inclinada "\", por lo que lo separamos para manejarlos indpendientemente.

El método PideClave, el más interesante de todo el código, se encarga de solicitar la clave al usuario de forma segura (lo veremos en el próximo post).

Usamos la clase ProcessStartInfo, aparecida en .NET 2.0, para lanzar el proceso indicado. Como vemos el código es directo excepto por dos o tres puntos interesantes:

1.- Establecemos la propiedad UseShellExecute a false. Esta propiedad sirve para especificar si se usará el Shell de Windows para lanzar la nueva aplicación o si por el contrario se lanzará directamente un proceso. La principal diferencia entre una u otra opción es que si esta propiedad es false podremos redirigir los flujos de consola (entrada, salida y errores) a voluntad. Además sólo nos permitirá lanzar ejecutables, que es el propósito de este programa. Si usásemos el valor true se podrían lanzar también los ejecutable a partir de un archivo asociado con éstos. Así, si pusiésemos "miDocumento.docx" se ejecutaría Microsoft Word, pero en nuestro caso tendríamos que poner el ejecutable siempre (lo que es más adecuado para el propósito de este programa). Todos los detalles en la página de MSDN para UseShellExecute.

2.- Sólo es posible asignar la clave en la propiedad PassWord usando una cadena segura, es decir, una clase SecureString, también aparecida con .NET 2.0. Más en el próximo.

3.- El método Start de la clase Process se usa para lanzar el proceso a partir de la información almacenada en la clase ProcessStartInfo.

El próximo día comentaré lo que es para mi más interesante de todo este programa: cómo pedir al usuario que introduzca su contraseña por consola de una manera segura, sin almacenarla nunca en memoria y usando la clase SecureString. También dejaré entonces el código de ejemplo completo.

¡Hasta pronto!

El próximo día 1 de Julio tengo el gusto de participar como ponente en este interesante evento on-line de SecondNUG, el grupo de usuarios de .NET en Español que cada vez está teniendo más tirón:

En este evento Luis Miguel Blanco se encargará de desvelar los secretos y dudas más comunes de las rejillas en programas de escritorio (Windows Forms), mientras que yo me encargaré de hacer lo propio con el control GridView de ASP.NET para desarrollo Web. Será una hora para cada control con contenidos eminentemente prácticos (mucha demo) y trataremos de resolver las dudas más comunes que se suscitan en los foros de MSDN.

Apúntate pulsando sobre la imagen de más arriba.

Siguiendo con esta mini-serie (parte I y parte II) sobre el mantenimiento de las sesiones en ASP.NET, en esta ocasión me voy a centrar en cómo evitar que una sesión caduque por inactividad mientras el usuario tenga el navegador abierto. Esta situación puede ser deseable en muchas ocasiones.

Por ejemplo, nada fastidia más que estar redactando en el navegador directamente un artículo para un boletín o un blog (como es el caso) y que cuando vas a enviarlo y pulsas el botón "Publicar" te salga un mensaje diciéndote que la sesión ha caducado (y por supuesto has perdido todo lo que escribiste). En este caso es interesante que la página de edición mantenga la sesión viva mientras tú estás trabajando en ella, aunque te vayas a comer y vuelvas dos horas más tarde. Este caso se da por ejemplo en aplicaciones como nuestro servicio MAILCast^®, en el que hemos implementado una solución similar a la que describiré ahora.

Otro ejemplo lo tenemos en servicios como nuestra plataforma de teleformación SELF, con la que impartimos los cursos de campusMVP. Si un alumno está parado en una lección que contiene por ejemplo un vídeo cuya duración es de media hora (la sesión normal dura 20 minutos) o que tiene un laboratorio que va siguiendo paso a paso y tarda una hora en hacerlo, cuando finalmente quiera pasar al siguiente punto del índice se encontraría con la desagradable sorpresa de que la sesión ha caducado y que por lo tanto debería volver a autenticarse en el sistema. Esto no es aceptable claramente, así que tenemos que buscar una solución para evitarlo.

Lo primero que se le suele ocurrir a todo el mundo es aumentar el tiempo de caducidad de sesión bien tocando la configuración de IIS (mala cosa pues afecta a toda la aplicación) o bien aumentándolo para una página específica. El probvlema que tiene esto es que nunca sabes cuánto es un tiempo razonable y que además en muchas ocasiones variará enormemente de unas páginas a otras al ofrecer éstas contenido dinámico. Además si luego realmente el usuario no permanece en la página y se limita a cerrar el navegador, la sesión se quedará ocupando memoria y recursos del servidor durante mucho rato sin necesidad alguna. Así que alguna forma mejor tiene que haber...

Lo cierto es que conseguirlo es muy fácil. ¿Cómo se consigue de manera natural que una sesión se mantenga activa?, pues como sabemos recibiendo peticiones del usuario en el servidor, las cuales renuevan el periodo de caducidad en cada petición.

Pues entonces la solución está clara: vamos a lanzar peticiones al servidor en segundo plano usando JavaScript, de forma que se reciban en el servidor y mantengan la sesión activa. Ni más ni menos.

Para ello una forma habitual de hacerlo sería usar el objeto XmlHttpRequest en el que se basan las aplicaciones AJAX, si bien como veremos enseguida ni siquiera hace falta complicarse tanto.

El "truco" es que el recurso que llamemos en el servidor no puede ser cualquiera, sino que tiene que ser alguno que pase por el "pipeline" de ASP.NET que incluya gestión de sesiones. Lo mejor, por tanto, es llamar a una página .ASPX o a un manejador .ASHX.

La llamada la podemos hacer usando un simple script que solicite más script al servidor, con un código similar a este:

//Ejecuta el script en segundo plano evitando así que caduque la sesión de esta página
function MantenSesion() 
{                
    var CONTROLADOR = "refresh_session.ashx";
    var head = document.getElementsByTagName('head').item(0);            
    script = document.createElement('script');            
    script.src = CONTROLADOR ;
    script.setAttribute('type', 'text/javascript');
    script.defer = true;
    head.appendChild(script);
} 

Con esto lo que hacemos es crear un nuevo script en la cabecera de la página y añadirlo al DOM del navegador, momento en el cual se solicitará al servidor. El origen del script en este caso es un simple manejador ASHX (que debe implementar la interfaz IRequiresSessionState para que se tenga acceso a la sesión y por lo tanto entre en el proceso el proveedor de sesiones) y que devuelve en este caso un simple comentario de script, ya que lo único que buscamos es que se mantenga activa la sesión gracias a la petición.

Podemos conseguir algo similar usando un iframe oculto al que mediante script le cambiamos la propiedad "src" para que pida una página ASPX del servidor la cual se devuelve vacía pero nos sirve para el mismo propósito. Es decir, no es necesario recurrir a técnicas más sofisticadas como la de XmlHttpRequest y nos aseguramos que funcionará hasta en navegadores bastante antiguos.

La otra cosa que hay que considerar es el intervalo de tiempo que usaremos para llamar a esta función de JavaScript que mantendrá la sesión viva. Si la sesión dura 20 minutos podemos llamar cada 18 minutos o así (para asegurar) y así no impactará demasiado en el servidor que mandemos estas peticiones extra pues son muy escasas. Por lo tanto la mejor forma de proceder es establecer un temporizador que llame a dicha función por ejemplo cada el 90% de la duración de la sesión de ASP.NET. Se consigue de forma muy sencilla simplemente añadiendo un código como este al final de nuestra página ASPX:

<script language="javascript" type="text/javascript">
    setInterval('MantenSesion()', <%= (int) (0.9 * (Session.Timeout * 60000)) %>);
</script>

Así lo que conseguimos es crear un temporizador que se repetirá cada 'x' milisegundos y que llamará a la anterior función para mantener la sesión abierta. Se multiplica por 60.000 el tiempo de sesión porque éste está expresado en segundos y el intervalo del temporizador debe ir en milisegundos. En el caso del tiepo de sesión por defecto (20 minutos) este código generaría un temporizador que renovaría la sesión cada 1.080.000 milisegundos, o sea, cada 18 minutos.

Como vemos es muy fácil de conseguir y puede resultar muy útil en ocasiones.

¡Espero que te sirva!

En mi anterior post comentaba brevemente el funcionamiento más común de los sistemas de sesiones de los servidores de aplicaciones Web y en particular el de ASP y ASP.NET. Éste lleva acarreados una serie de problemas cuando ls sesiones terminan por lo que comentaba una forma sencilla de detectar que una sesión había caducado. En dicho post comenté que iba a explicar una forma más "profesional" y autocontenida de comprobar si una sesión está activa o no en ASP.NET, y a eso voy...

El mecanismo para comprobar si la sesión actual está caducada o no pasa por el uso de una propiedad no muy conocida de la clase HttpContext: IsNewSession. Esta propiedad devuelve 'verdadero' únicamente cuando se acaba de crear una sesión para el usuario justo en la petición actual. Una sesión se crea cuando se crea una variable de sesión por primera vez. Al hacerlo se envía al cliente una cabecera con el identificador de sesión que es el que posteriormente el navegador envía de nuevo al servidor en cada petición, permitiendo así detectar a qué sesión pertenece dicha petición (suena más complicado de lo que es). Esta cabecera es realmente una cookie que sólo se mantiene activa mientras dura la sesion (cookie de sesión) ya que nunca se persiste a disco. La cookie se identifica con el nombre "ASP.NET_SessionId".

El navegador no es consciente de si la sesión ha caducado o no en el servidor, por lo tanto sigue enviando todo el tiempo la cabecera sin saber si realmente vale para algo. El sistema de detección de la sesión caducada se basa en que, cuando la sesión caduca, en la siguiente petición que se haga al servidor se crea una nueva sesión. A diferencia de la primera vez en la que se crea la sesión, cuando ésta caduca ya existe la cebecera "ASP.NET_SessionId" en las peticiones del navegador. Por lo tanto una petición cuya sesión acaba de caducar es aquella en la que se crea una nueva sesión pero al mismo tiempo existe esta cabecera en la petición.

Puesto en forma de código esta condición se expresa de modo similar a este:

    public static bool IsSessionTimedOut()
    {
        HttpContext ctx = HttpContext.Current;
        if (ctx == null)
            throw new Exception("Este método sólo se puede usar en una aplicación Web");

        //Comprobamos que haya sesión en primer lugar 
        //(por ejemplo si por ejemplo EnableSessionState=false)
        if (ctx.Session == null) 
            return false;   //Si no hay sesión, no puede caducar
        //Se comprueba si se ha generado una nueva sesión en esta petición
        if (!ctx.Session.IsNewSession)
            return false;   //Si no es una nueva sesión es que no ha caducado
        
        HttpCookie objCookie = ctx.Request.Cookies["ASP.NET_SessionId"];
        //Esto en teoría es imposible que pase porque si hay una 
        //nueva sesión debería existir la cookie, pero lo compruebo porque
        //IsNewSession puede dar True sin ser cierto (más en el post)
        if (objCookie == null)
            return false;

        //Si hay un valor en la cookie es que hay un valor de sesión previo, pero como la sesión 
        //es nueva no debería estar, por lo que deducimos que la sesión anterior ha caducado
        if (!string.IsNullOrEmpty(objCookie.Value))
            return true;
        else
            return false;
    }

He incluido comentarios para que sea más fácil seguir la lógica.

Como vemos lo primero que se hace es obtener una referencia al contexto actual de la petición Web (si no existe es que no estás usando este método en una petición Web). Lo siguiente que se hace es comprobar si hay sesión. No siempre existe ya que se puede desconectar la gestión de sesiones en la página o en toda la aplicación (a través de un ajuste en web.config). Luego es cuando viene lo que expliqué en el párrafo anterior: se comprueba si hay una nueva sesión con IsNewSession. Siendo así se obtiene una referencia a la cookie de sesión. Si no existe es que es la primera vez que se crea la sesión para este usuario, pero si existe y contiene algún valor es que existió una sesión anterior y por lo tanto, al estar creándola de nuevo, se había caducado.

He dejado este código en una clase llamada SessionTimeOut para que si tienes interés te la bajes directamente lista para usar.

En el próximo post comentaré casi lo contrario a esto: cómo conseguir que la sesión no caduque mientras el usuario tenga el navegador abierto, aunque no haga petición alguna en mucho rato y sin ampliar el tiempo de sesión ad infinitum, lo cual tiene muchas aplicaciones prácticas.

El protocolo HTTP es un protocolo sin estado. Esto quiere decir que no hay forma incluída en el protocolo para discernir una petición de otra. Por lo tanto cuando llegan dos peticiones al servidor no hay forma de saber si pertenecen al mismo usuario (ni siquiera la IP como alguna gente me dice a veces, ya que muchas personas pueden salir a Internet desde la misma dirección IP (mismo router y conexión). Además los identificacdores estáticos como ese no son fiables nunca).

Dicho esto, lo que está claro es que en la práctica sí que existe forma de distinguir que dos peticiones vienen del mismo usuario. Es el concepto que sostiene las sesiones de ASP.NET y otras tecnologías. ¿Cómo se consigue?. Bueno, existen muchas formas de hacerlo, pero la más habitual consiste en utilizar una cookie de sesión para almacenar un valor único que identifica de manera inequívoca a cada usuario. Estas cookies de sesión son realmente cabeceras HTTP que el navegador envía de vuelta al servidor en cada petición que hace al mismo. Un módulo especializado en el lado servidor lee estas cabeceras e inicializa en cada petición el contexto de la sesión correspondiente. Es por ello que luego podemos usar de manera natural el objeto Session (de la clase HttpSession), que nos da la ilusión de que disponemos de un ámbito de almacenamiento atado al usuario actual que se conserva entre peticiones. No voy a entrar en más detalles ya que cualquier programador experimentado con ASP.NET está familiarizado con este concepto.

Al trabajar con sesiones almacenamos en variables de sesión valores que queremos conservar entre peticiones para cada usuario. Para conservar los recursos del servidor estos valores se almacenan sólo durante un tiempo determindo tras el cual si no hay nuevas peticiones se eliminan. En cada nueva petición este tiempo de vida se prorroga pudiendo mantener la sesión "activa" mientras haya actividad. En ASP.NET/IIS, por defecto las sesiones tienen un tiempo de validez de 20 minutos. Si pasan más de 20 minutos desde la última petición de un usuario la sesión correspondiente a éste se termina, eliminándose de memoria toda la información acumulada.

Y ahí radica precisamente un problema muy habitual de muchos programadores, ya que al caducar la sesión de repente muchas cosas pueden dejar de funcionar, ya que información que necesitábamos deja de estar disponible. El problema no suele ser si está disponible o no, sino si no está disponible porque nunca se estableció o por que la sesión ha caducado eliminándola. Con toda seguridad cualquier programador experimentado de ASP o ASP.NET (o, incluso, otras tecnologías como PHP) se ha encontrado en una situación similar en mútliples ocasiones.

¿Existe alguna forma de determinar si la sesión actual ha caducado?

Pues sí. De hecho hay varios. Ahora voy a contar uno bastante obvio y rápido de implementar, si bien algo "pedrestre" y engorroso pues implica una coordinación entre dos partes de la aplicación.

Consiste en algo bastante obvio y que consiste en establecer una variable de sesión automáticamente al iniciar ésta (en el evento Session_Start que se lanza en ese momento). Más tarde basta con comprobar si esta variable única está establecida o no para saber si, en efecto, ésta sigue activa. Sería así:

    void Session_Start(object sender, EventArgs e) 
    {
      Session["Activa"] = true;
    }

Luego podemos comprobar si esta variable es nula o no para decidir si la sesión está activa, ya que la variable existirá siempre que exista la sesión. Muy fácil.

No obstante es un método algo "chapuzas" porque hay que acordarse de establecer la variable en el evento Session_Start en el archivo Global.asax, y luego estar leyéndola por ahi para comprobarlo.

Así que para remediarlo en el próximo post contaré la forma de averiguarlo de modo mucho más "profesional", en un método auto-contenido e independiente que para averiguarlo se basa en el funcionamiento del sistema de sesiones basado en cookies de sesión. En un siguiente post hablaré de (casi) lo contrario: cómo mantener la sesión abierta indefinidamente sin necesidad de aumentar el tiempo de sesión.

¡Hasta pronto!

Hoy hace exactamente un mes que no publicaba nada en el blog. Me fastidia, y tengo muchas cosas interesantes en la recámara esperando a tener un rato para publicarlas, pero es que he tenido (y tengo) una temporada muy mala. O muy buena, según se mire.

Estoy trabajando "a dolor" en el nuevo catálogo de cursos de campusMVP, que verá la luz en làs próximas semanas. Espero que os guste, porque vamos a pegar el cambio más grande en el proyecto desde que nació. Un currazo. Ya os iréis enterando, pero os va a gustar :-) Iremos sacando varias cosas nuevas poco a poco, algunas creo que de gran interés.

También he estado muy liado preparando un curso de e-mail marketing que he impartido a varios clientes tanto presencialmente como en directo a través de Internet. Además he tardado más de lo normal porque he procurado ser muy ordenado y sistemático, ya que este curso constituye la base para un libro sobre el tema que hace un año que tengo en proyecto, y que espero que vea la luz antes de final de año (bastante antes espero, de hecho). Ya os lo contaré también aquí.

Además he hecho la beta de uno de los nuevos exámenes de certificación, he estado actualizando material para mis cursos on-line de campusMVP (me falta poquito para acabar), algún artículo para PC World y dotNetMania que estoy terminando también, escribiendo posts en inglés y castellano para TheEmailingExperience y otro blog que de momento es privado (y un día de estos se hará público, espero), coordinando nuevos libros de Krasis Press que verán la luz en los próximos meses, he asisitido (como alumno) un curso de 3 días sobre management en Madrid, me ha tocado el grupo de alumnos más demandante de la historia de campusMVP que me han tenido y me tienen contestando dudas duramente desde hace bastantes semanas (sois unos cracks, pero me alegraré cuando terminéis, jajaja), he estado de cumpleaños (y por lo tanto de juerga también)...

Y por supuesto tengo una empresa que dirigir y una familia a la que hacerle caso, así que como comprenderéis alguna cosa tenía que dejar un poco de lado. Y esta vez le ha tocado a este blog personal.

Desde aquí quiero pedirle disculpas también a mis trabajadores (mucho mejor dicho, mis compañeros de trabajo, sufridores de mi "hurañismo") porque no he podido hacerles apenas caso, mucho menos que de costumbre, que ya es decir. Sois unos "crases". Espero poder compensaros.

El la foto de este post no soy yo, pero podría serlo perfectamente :-)

A partir de hoy retomaré la actividad bloguera habitual (o casi) y procuraré publicar unas cuantas cosas interesantes como de costumbre.

¡Nos vemos!

JM.

Los sistemas Windows actuales son capaces de gestionar varias sesiones de trabajo simultáneas, para diferentes usuarios. Windows Xp o Vista sólo permiten una sesión interactiva al mismo tiempo pero es una simple cuestión de licencia, ya que en realidad internamente las gestionan de ese modo (de hecho existen programas en el mercado que desbloquean esta limitación). En Windows Server con terminal Services o en modo administrativo esto ya no es una limitación y se pueden tener tantas sesiones de usuario interactivas abiertas como soporte el hardware.

Puede que a nuestro programa le venga bien saber en un momento dado si un determinado usuario está con una sesión iniciada o no. O incluso obtener una lista de usuarios que están actualmente en el sistema.

La forma de conseguirlo es mediante una consulta WMI (Windows Management Instrumentation). En el siguiente fragmento se ve un método que, dado un nombre de dominio y un nombre de usuario comprueba si éste está "logueado" actualmente en el sistema:

    private static bool IsUserLoggedOn(string sDominio, string sNomUsuario)
    {
        string _dominio = "";
        string _usuario = "";
    
        ObjectQuery oQuery = new ObjectQuery("select * from win32_computersystem");
    
        ManagementObjectSearcher oSearcher = new ManagementObjectSearcher(oQuery);
    
        ManagementObjectCollection oReturnCollection = oSearcher.Get();
        if (oReturnCollection.Count >= 1)
        {
            foreach (ManagementObject oReturn in oReturnCollection)
            {
                string nombre = oReturn["UserName"].ToString();
                if (nombre.Length > 0)
                {
                    int index = nombre.IndexOf('\\');
                    _dominio = nombre.Substring(0, index).ToLower();
                    _usuario = nombre.Substring(index + 1).ToLower();
                    
                    if (sDominio.ToLower() == _dominio.ToLower() && sNomUsuario.ToLower() == _usuario.ToLower() )
                    return true;
                }
            } 
        }
        return false;
    }

Para ello se usa la clase ObjectQuery, que sirve para definir consultas WMI, y la clase ManagementObjectSearcher, que es la encargada de realizar la consulta. Ambas están en el espacio de nombres System.Management.

Ahora podemos escribir por ejemplo:

Console.WriteLine(IsUserLoggedOn("Josecoreduo", "jose"));
Console.ReadLine();

Para averiguar si el usuario "josecoreduo\jose" está actualmente autenticado en el sistema.

La consulta lanzada en realidad nos permite obtener muchísima otra información sobre el equipo de modo similar al visto, a través de los miembros de la clase Win32_ComputerSystem, incluso de equipos remotos sobre los que tengamos permisos.

Espero que os resulte útil!

Leo en Engadget esto y la verdad es que me llama la atención el experimento:

"Habíamos visto esas fotos de un MacBook Pro corriendo 150 aplicaciones en Mac OS X, pero con esto demostramos que Windows no se queda atrás... (aunque sí se queda atrás, porque son sólo 108 aplicaciones). Según vemos en el video (después del salto), el ordenador que usan debe ser muy bueno (sabemos que tiene 3,25GB de RAM), porque aún con todas esas aplicaciones, la velocidad sigue siendo aceptable."

Interesante...

Una pregunta muy típica con la que me suelo encontrar es la de: "¿Cómo puedo hacer para proteger la información de mi cadena de conexión a la base de datos si ésta la pongo en mi web.config?".

Bueno, lo primero que he de decir es que siempre conviene usar mejor la seguridad integrada de Windows (cadena de conexión con "Integrated Security=SSPI;") que las cuentas propias de SQL Sever, por lo que en ese caso no sería necesario encriptar nada. Por otro lado existe un manejador de peticiones de IIS que impide que el contenido de los archivos web.config sea accedido mediante HTTP, por lo que sólo debería preocuparnos que alguien viera nuestra configuración en caso de tener un agujero de seguridad en el servidor o bien en nuestro código (por cierto, aprende a evitarlos), en cuyo caso tendríamos un problema mucho mayor que el hecho de que sepan las credenciales de un usuario de SQL Server, que ya de por si debería estar bastante limitado en cuanto a permisos.

No obstante es interesante saber que en ASP.NET 2.0 o 3.5 podemos encriptar cualquier sección de nuestro web.config de forma sencilla y transparente para nuestro código.

Podemos hacerlo por código, pero lo más sencillo y lo que usaremos casi todas las veces es la herramienta de línea de comandos aspnet_regiis.exe, ubicado en la carpeta "C:\Windows\Microsoft.NET\Framework\v2.0.50727". Sólo hay que pasarle el tipo de proveedor de cifrado que queremos usar (-prov), el modificador "-pef" para indicar que queremos cifrar una ruta física, la sección a encriptar, y la ruta en el disco duro donde está el web.config a cifrar.

Por ejemplo:

aspnet_regiis.exe -pef "connectionStrings" "C:\miRaizIIS\MisitioWeb" –prov "DataProtectionConfigurationProvider"

Que indica que queremos cifrar la sección "connectionStrings" del web.config ubicado en "C:\MiRaiz\MiStioWeb", usando para ello el proveedor de la DPAPI (más sobre esto ahora).

De este modo obtendremos una cadena del estilo de esta:

 <connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">
  <EncryptedData>
   <CipherData>
      <CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAt ...... +hXziceYxOxY=</CipherValue>
   </CipherData>
  </EncryptedData>
 </connectionStrings>

(he quitado la mayor parte de la cadena cifrada porque es muy larga).

Lo más estupendo de esto es que no tendremos que tocar ni una sola línea de nuestro código para que funcione, ya que ASP.NET descifra de manera transparente la cadena de conexión al leerla desde la configuración.

Con el parámetro -prov (opcional) podremos especificar el proveedor de cifrado que queremos utilizar. Por defecto se nos proporcionan dos: el mecionado "DataProtectionConfigurationProvider" que cifra usando la DPAPI (Data Protection API de Windows), o bien el "RsaProtectedConfigurationProvider", que usa una pareja de claves pública/privada para cifrar y descifrar, y es el que se usará por defecto si no especificamos ninguno. Si quisiésemos usar un cifrado propio podemos construir una clase proveedora y especificarla con -prov al usar esta herramienta.

Desde mi punto de vista es mejor usar siempre DPAPI, ya que es una criptogra´fia muy segura y está atada por completo al equipo en elq ue se ha realizado el cifrado. De este modo aunque alguien lograse leer el archivo web.config y llevárselo a otro equipo no podría descifrarlo. Por este mismo motivo, una nota de precaución: debes usar esta técnica directamente en el servidor en el que va a estar la aplicación funcionando, puesto que si por ejemplo cifras en tu equipo de desarrollo y luego lo mueves a un servidor de producción, no se podrá descifrar la sección una vez allí. Así que haz el cifrado en el equipo donde va a funcionar la aplicación.

Se puede cifrar cualquier sección del web.config, y no sólo la de las cadenas de conexión. Las únicas que nose pueden cifrar son estas:

    *  <processModel>
    * <runtime>
    * <mscorlib>
    * <startup>
    * <system.runtime.remoting>
    * <configProtectedData>
    * <satelliteassemblies>
    * <cryptographySettings>
    * <cryptoNameMapping>
    * <cryptoClasses>

Las demás no hay problema ninguno si las ciframos, y se usarán del mismo modo, siendo el descifrado transparente para el programador.

¿Y si me olvido de lo que ponía y necesito volver a tenerlas en claro?

No hay problema. Podemos usar el mismo ejecutable con la opción -pdf para descifrar:

aspnet_regiis.exe -pdf "connectionStrings" "D:\Logistia\Codigo\LogistiaWeb"

Con esto conseguiremos que la sección vuelva a mostrar su contenido en claro.

Espero que te sea útil :-)

Si hay una cosa que me revienta es que se me desordenen los accesos directos que tengo colocados en mi escritorio. Como tipo ordenado y rigoroso que soy, mis accesos directos no están colocados de cualquier forma, sino que los tengo agrupados de una manera lógica (para mi, claro), de forma que pueda encontrar rápidamente lo que busco. Lo que más tengo son accesos directos a Internet con direcciones de consulta, cosas de las que me quiero acordar, etc...

Por eso, cuando cambias la resolución, tienes un problema con los drivers de pantalla (como los que asistísteis a mi charla del lanzamiento de VS2008 recordaréis), o cualquier otra circunstancia, me paso media hora ordenandolos de nuevo. Y no estoy para perder el tiempo en chorradas. No sé cómo una cosa tan común como está no la incorpora Windows de serie. Parece mentira.

El caso es que me dió por ver si había forma de conseguirlo. Y efectivamente la hay, como era de esperar. Resulta que, nada más y nada menos que en el kit de recursos de Windows NT (ojo, NT, no ha llovido ni nada), se incluye una DLL llamada layout.dll que sirve precisamente para eso, y que aún hoy en día, tantos años después, sigue funcionando en XP o Vista sin problema. La he metido en un ZIP que puedes descargar aquí: layout.zip (4 kB). Creo que esta DLL se le atribuye al mítico Jeffrey Richter que la escribió como ejemplo de uno de sus libros.

El caso es que te bajas el ZIP, lo sdecomprimes y tienes dentro dos archivos: layout.dll y layout.reg.

Copia la DLL a C:\Windows\System32\ o la carpeta quivalente en tu sistema. Luego haz doble click sobre el archivo de registro y cuando te pregunte acepta que la información se pueda agregar al registro.

A partir de ese momento dispones de dos nuevas opciones en el menú contextual del elemento "Equipo" (o "Computer" en ingles) de tu menú de inicio, y sólo hay. Con ellos podrás guardar y posteriormente restaurar la posición de los elementos que tengas en el escritorio.

Ten la precaución de usar la opción de guardar cada vez que hagas un cambio sustancial en la disposición de elementos del escritorio o cuando añadas nuevos accesos directos.

No funciona en 64 bits

La pega de esta DLL es que sólo funciona en versiones de 32 bits de Windows. Si estás utilizando una versión de 64 bits no te servirá de nada. Por suerte un programador ¿ruso? llamado Serge Baranov, ha desarrollado una versión de esta utilidad que funciona en 64 bits, y que es la alternativa que tienes en este caso. La puedes descargar desde la página de AMIP Tools.

Espero que te resulte de utilidad.