Hoy he estado perdiendo un buen rato con esta tontería. Y es que parece mentira, pero si metes un <iframe> en tu página y le estableces sus propiedades width y height al 100% para que ocupen toda la página sólo te hace caso el ancho. El alto no funciona, da igual que lo pongas en sus atributos o en sus estilos CSS. No hace ni caso :-( Tras romperme la cabeza unr ato he estado buscando en Internet y hay soluciones para todos los gustos, la mayoría de las cuales no funcionan. Además si funcionan en Internet Explorer no funcionan en Firefox o al revés. Es un verdadero peñazo. Al final la solución pasa por establecer una serie de atributos para algunos tags de la página, así: <style type="text/css">    html, body, div, iframe { margin:0; padding:0; height:100%; }    iframe { display:block; width:100%; border:none; }</style> Si no haces esto no hay forma de que pille el alto completo de la página. Así que ya lo sabes. Espero que esto... [Más]

Este es uno de los problemas/bugs más raros con los que me he topado en años, y puede llegar a ser desesperante. Si has llegado aquí a través de una búsqueda de Google porque tienes el problema que indico en el título del post, estoy seguro de que me vas a dejar una nota de agradecimiento por el consejo :-) Hace unos días hicimos una nueva plantilla estética para un cliente de nuestra plataforma de e-Learning, SELF. La plataforma tiene un sistema muy potente de plantillas estéticas que permite personalizar mucho la estética y parte de la funcionalidad de la interfaz. Se pueden asociar plantillas a los diferentes campus (entornos cerrados de formación) y también se pueden asignar muchas plantillas/fachadas diferentes a cada campus de forma que se pueda acceder con aspectos diferentes para cada cliente al mismo campus a través de diferentes URLs o directorios virtuales. Una de estas plantillas, preciosa por cierto, provocaba un extraño efecto sobre todas y cada una de las páginas ... [Más]

La semana pasada os contaba en un post la forma de eliminar la caché de salida de una página a voluntad, antes de que caduque de manera "natural", usando el método RemoveOutputCacheItem. Este método tiene el problema de que debemos hacerlo desde una página diferente a la que está cacheada, porque en ésta los eventos de servidor (incluyendo el click de un botón) no saltan. Además dejé planteado un caso relativamente común que se puede dar y en el que resultaría útil disponer de otra forma de controlar si se hace caché o no. Imagina esta situación: tienes una página en caché que los usuarios normales pueden ver pero no editar, pero que los administradores pueden cambiar usando los botones apropiados. Si simplemente activas la caché para que los usuarios vean la versión cacheada de la página, como hemos visto, ninguno de los eventos normales saltará, así que los administradores tampoco podrán editar nada, ni tampoco se verán los cambios que han hecho hasta que la caché se refresque. ¿Cóm... [Más]

Los que me conocéis o habéis ido a alguna de mis charlas sabéis que soy un gran defensor de las técnicas de Caché de salida en las páginas para mejorar el rendimiento y la respuesta de las aplicaciones. De hecho en este blog he hablado ya bastantes veces sobre la Caché en sus diversas variantes. Así que quizá resulte chocante que hoy vaya a hablar sobre justo lo contrario: cómo eliminar la caché de salida (OutputCache) de una página. Como es sabido, para habilitar la caché de salida de una página o control lo único que tenemos que hacer es añadir una directiva similar a esta al  principio de la página, justo tras la directiva de página: <%@ OutputCache Duration="60" VaryByParam="None" %> Los parámetros que se pueden usar son variados y no voy a entrar aquí en detalles pues todo programador de ASP.NET debe conocerlos (si alguien necesita formación sobre desarrollo web, ya sabe ;-)). Es posible hacer caché de la página completa, sólo de algunas partes, de todo menos algunos... [Más]

Los que vísteis hace unas semanas mi vídeo sobre mantenimiento de sesiones en operaciones largas de cliente con ASP.NET seguro que os interesa saber que ahora podéis verlo a alta calidad y descargarlo en diversos formatos para su estudio pormenorizado. Microsoft lo ha publicado en Channel9 así que podéis verlo ahora también aquí: http://channel9.msdn.com/posts/Daniel+Garzon/Mantenimiento-de-Sesiones/ El código de ejemplo se puede descargar desde el post de mi blog referenciado en el primer enlace. Espero que os resulte útil :-)

En los  últimos posts he estado hablando sobre la seguridad de ASP.NET basada en Forms. Esto ha traído algunas preguntas por parte de los visitantes. Una de ellas, bastante común, es la de cómo almacenar información adicional atada a los usuarios que hemos autenticado.La API de Membership que viene con ASP.NET, y en concreto el proveedor de Membership para trabajo contra SQL Server (SqlMembershipProvider) nos provee de los medios suficientes para almacenar la información básica sobre los usuarios, esto es, el nombre, su login y su clave, que es lo mínimo necesario para trabajar. En este gráfico puedes ver la estructura completa creada por ASP.NET (más bien por aspnet_regsql.exe) en nuestra base de datos para dar soporte a SqlMembershipProvider y relacionados.Obviamente casi siempre necesitaremos almacenar mucha más información sobre ellos, relacionándola de manera directa y sencilla para poder extraerla. Así, por ejemplo, podemos necesitar almacenar sus datos de contacto, infromac... [Más]

En mi anterior post hablaba sobre el funcionamiento de las cookies en los navegadores y de cómo podíamos usar una extensión estándar (HttpOnly) para intentar impedir que las cookies sean accesibles desde el lado cliente y sólo se puedan manejar desde el servidor. No obstante se trata de una medida que, de funcionar, complica un poco a los posibles piratas, pero no es una verdadera barrera de seguridad. Para empezar ni siquiera está soportada por todos los navegadores. Las cookies residen en el disco duro del usuario por lo que son fáciles de manipular por cualquiera. Además se envían al servidor en cada petición, por lo que cualquiera con un proxy estilo Fiddler puede leerlas y manipularlas antes de enviarlas al servidor. Es decir, las cookies son elementos realmente inseguros. A raíz de estas disquisiciones alguien me escribió preguntándome por la seguridad de la autenticación Forms de ASP.NET (la más habitual). Ésta se basa precisamente en la existencia de una cookie que identific... [Más]

Una de las técnicas de hacking de páginas web más conocidas es la de Cross-Site-Scripting o XSS. Mediante esta técnica, las aplicaciones Web vulnerables pueden ser atacadas para multitud de propósitos: servir de zombies para atacar a otras Webs inundándolas con peticiones, ejecutar código en zonas de seguridad menos restrictivas (como la local) o, sobre todo, robar la identidad de los usuarios del sitio vulnerable. Ha sido utilizado tradicionalmente en combinación con correos electrónicos maliciosos para entrar en sitios Web protegidos suplantando la identidad de usuarios autenticados. En mi curso de Desarrollo de aplicaciones seguras y seguridad de .NET monto un ejemplo completo de cómo utilizarlo en un supuesto sitio de banca electrónica (muy mal hecha y vulnerable), para robar la sesión del usuario y entrar en su cuenta. Este robo de sesiones se basa en la obtención mediante XSS de la cookie de sesión de un usuario, enviándola a un servidor bajo el control del atacante. Éste al rec... [Más]

La metodología clásica de creación de páginas Web recomienda que todos nuestros scripts se encuentren en la cabecera de la página. Está bien tener un orden pero realmente no es necesario. Es más, nadie nos dice que no podamos incluso tener varias cabeceras en la página, una por ejemplo, después de cerrar la etiqueta </body>, si queremos. Hay algunas aplicaciones que usan mucho JavaScript. Sobre todo ahora con el uso masivo de capacidades AJAX en las aplicaciones Web. Algunos de estos scripts son simples bibliotecas de funciones con decenas o cientos de ellas que lo único que hacen es retrasar la carga de página mientras son procesadas por el navegador, ya que éste no sólo carga cada Script sino que también lo interpreta y ejecuta a medida que lo va leyendo. En otros casos el script necesita tener acceso a todos los elementos de la página antes de poder actuar (es decir, el HTML de la página debe ser procesado por completo y el árbol DOM construido). Si lo colocamos en la cabecer... [Más]

Uno de los posts más visitados de mi blog es en el que comento cómo evitar que las sesiones caduquen por inactividad. Es la tercera parte de una serie de posts sobre caducidad de sesiones en ASP.NET. Ha habido también muchos comentarios y parece que a mucha gente le cuesta bastante implementar la solución, por lo que tras varias peticiones (tanto en mi blog original, JASoft.org, como en Geeks.ms) me he decidido a generar un vídeo práctico mostrando como se hace.  Es del estilo de los que tenemos en los cursos de campusMVP pero con mucha peor calidad, que viene impuesta por las limitaciones de SOAPBox. Lo cierto es que estos sitios de vídeo en Internet no son los más adecuados para este tipo de grabaciones por su elevada compresión, que limita la calidad, pero bueno... se deja ver. A ver si lo puedo colgar en Channel9 de Microsoft en breve y así que podáis verlo con major calidad: