Pues nada, hoy toca cuña publicitaria, pero creo que os va a interesar :-) Y es que hoy hemos lanzado nuestro nuevo catálogo de cursos de campusMVP. Y esto es sólo el principio, pues a lo largo del verano lo ampliaremos y además iremos lanzando muchas cosas nuevas que estamos seguros de que te van a encantar. Hemos hecho caso a todo lo que nos han dicho los alumnos últimamente y encontrarás muchas novedades: cursos más baratos, más tiempo para hacerlos, descuentos para desempleados, posibilidad de pagar todos los cursos con tarjeta y cursos gratuitos para que pruebes como se siente un alumno de campusMVP. Cuantos más cursos elijas más descuentos puedes obtener. Y también tenemos soluciones específicas para las empresas. Nunca fue tan fácil construirte una formación a la carta. Consulta nuestra nueva oferta formativa y aprovecha el verano para aprender. Échale un vistazo también a la nueva colección de cursos 'Al día en un día', que te permitirá controlar los fundamentos... [Más]

Como es sabido, desde hace ya bastantes años (1.999) la firma digital de documentos tiene val [Más]

En mi anterior post hablaba de cómo construir un programa "clon" de la utilidad de línea de comandos Windows RunAs. En esta primera parte vimos cómo se lanzaba un proceso suplantando a un usuario, que era el objetivo principal de la aplicación, si bien es la parte más fácil. La tarea que nos quedó pendiente de ver es la más complicada y consiste en solicitar al usuario la clave de manera segura, sin que llegue a estar almacenada en claro en la memoria siquiera. Para ello usamos la clase SecureString, que apareció para estos menesteres en la versión 2.0 del framework. Sin más vueltas vamos a ver directamente cómo se solicita dicha clave y pasamos a explicar los puntos de interés: private static SecureString PideClave(string nomUsuario) { Console.WriteLine("Escriba la contraseña para {0}:", nomUsuario); int top, left; ConsoleKeyInfo cki; SecureString clave = new SecureString(); top = Console.CursorTop;... [Más]

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 muest... [Más]

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 [Más]

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... [Más]

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ó... [Más]

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... [Más]

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...