Estos días he estado intentando instalar Office 2007 en un Windows XP recién instalado. El caso es que, inexplicablemente, y aunque ejecuté el instalador como administrador, una y otra vez recibía el mensaje siguiente:

"Windows installer service cannot update one or more protected windows files."

No podía entenderlo. Jamás me había pasado. El caso es que sorprendentemente y aunque había instalado todo Windows XP prácticamente la solución consiste en añadir manualmente un archivo que no tiene el sistema. Para encontrar la solución en Internet, tela...

1. Desde el disco de instalación de Windows en su carpeta i386 busca el archivo FP40EXT.CAB y ábrela.

2. Buscaa dentro el archivito: fp4ault.dll.

3. Extráelo a la carpeta C:\Archivos de programa\Archivos comunes\microsoft shared\web server extensions\40\bin

Ahora intenta instalar de nuevo Office 2007 y verás como te funciona. Vivir para ver :-(

Lo cierto es que no sé para qué rayos quiere la instalación una DLL de Frontpage, pero espero que a alguien le ahorre mucha frustación.

Es que este tío, Javier Aguilera, es muy bueno :-)

La verdad es que esto lo sé desde hace ya tiempo pero hasta ahora no me he decidido a hacerlo público.

Tengo la suerte y el honor de ser ponente en el próximo TechEd Developers, el evento internacional para desarrolladores más importante dentro del mundo Microsoft. Y encima tengo la suerte de compartir ponencia con mi buen amigo Iván González, un crack:

Pulsa para aumentar

Nuestra ponencia se titula "ASP.NET Instrumentation and Health Monitoring" y os dejo el "abstract" de la misma para que sepáis de que va:

"It´s not everything about program functionality and functional requirements. What about post-deployment health and monitoring?. Keep your programs productive and virtually bug-free.

Develop ASP.NET applications aware of the event log, performance counters and trace listeners, keep applications under control and get ready before problems strike.

Dive into the IIS7 expanded monitoring & diagnostics capability through features like Runtime Status & Control data, Failed Request, etc...

We will see how to implement health measures in both application code (ASP.NET 3.5) and hosting (IIS 7.0) in order to ensure continuity."

Está en inglés porque la ponencia será en inglés, claro (es un evento internacional). Tendremos la suerte de compartir "cartel" con gente tan conocida como David Chappell, Steve Lasker, Michael Howard o Daniel Moth, por citar unos pocos.

La verdad es que tanto Iván como yo estamos muy contentos porque creo que se pueden contar con los dedos de la mano los españoles que han tenido la oportunidad de ser ponentes en TechEd. Además este año estamos que nos salimos los españoles, porque aparte de Iván y yo también será ponente Miguel Jiménez y nuestro ponente más internacional y autor del libro de Windows Communication Foundation de Krasis Press, Hadi Hariri.

¡Deseadnos suerte!

Y por supuesto, si estás por Barcelona la semana del 10 de noviembre a ver si te vemos por allí :-)

En mi anterior post os hablaba sobre la forma de poder utilizar varios certificados SSL en un mismo servidor y las posibilidades y limitaciones técnicas que existían.

Un certificado de servidor para SSL suele ser un producto caro. El precio en una entidad certificadora decente van desde unos pocos cientos a más de 1.000 euros, dependiente del tipo de certificado. Además es un proceso tedioso ya que hay que demostrar fehacientemente que somos quiénes decimos ser (que es de lo que va todo esto realmente, claro), lo que implica envío de papeles para su verficación, llamadas, faxes, etc... Conviene seleccionar una entidad certificadora conocida ya que de este modo su certificado raíz, que la verifica a ella primeramente, estará ya instalada en nuestro equipo, cosa que no ocurre con otras menos comunes (y supone una barrera comercial importante para éstas últimas). Todo el sistema de infraestructura de clave pública (PKI) se sustenta en esas relaciones de confianza jerarquizadas.

El objetivo de un certificado digital de servidor (para SSL) es triple ya que pretende lo siguiente:

1.- Autenticación del servidor: sirve para constatar ante los usuarios, de forma fiable, que el servidor al que se están conectando es quién dice ser y que por lo tanto nos estamos conectando de verdad a nuestro banco o servicio on-line.

2.- Cifrado de comunicaciones: la clave pública del servidor se utiliza para cifrar las comunicaciones iniciales, en las que se acuerdan el método de cifrado simétrico y la clave de cifrado que se utilizarán para cifrar todas las comunicaciones posteriores. Eso asegura la confidencialidad de las comunicaciones entre cliente y servidor, y es uno de los motivos por los que no se pueden simultanear certificados como hemos visto en el post anterior, ya que hasta la URL que se solicita viaja cifrada.

3.- No repudio de las comunicaciones realizadas por parte del servidor.

Cuando estamos desarrollando una aplicación y la queremos probar con SSL, o bien cuando sólo queremos el certificado SSL para un uso restringido (por ejemplo para nuestros dos o tres usuarios móviles que se quieren conectar cuando están fuera de la oficina), quizá el coste de un certificado real no está justificado. Para generar un certificado propio podemos poner en marcha nuestra propia infraestructura PKI, para lo cual Windows Server viene preparad. Aunque nos resultará fácil montar una PKI propia puede que no esté justificado todo el trabajo que conlleva para genrar uno o dos certificados.

Para permitir a los desarrolladores el uso de certificados SSL sin tener que comprarlos o generarlos con una PKI propia, en el interesante Kit de Recursos de Windows Server 2003 que ya hemos mencionado en el anterior post, se incluye una pequeña utilidad de línea de comandos que te va a encantar. Se trata de SelfSSL.exe.

Este ejecutable nos permite generar para cualquier servidor virtual de IIS un certificado digital SSL que está firmado por nosotros mismos. Lo genera y además lo instala y deja listo para su uso. La utilización de SelfSSL es muy sencilla:

Así, para generar un certificado SSL para un servidor virtual que tenga una validez de un año y que valide al dominio zonasegura.midominio.com tendría que escribir algo como esto:

selfssl /T /N:CN=zonasegura.midominio.com /V:365 /S:1669802537

El valor para el parámetro /S es el identificador d enuestro servidor virtual y, como hemos visto, lo sacamos con la utilidad IIS Metabase Explorer. Además he añadido el parámetro /T para que el certificado generado se instale en la lista de certificados de confianza del navegador local. De este modo en el servidor de pruebas no recibiremos advertencias sobre que el origen del certificado no se puede validar.

Y es que este es el mayor inconveniente de estos certificados: al acceder mediante SSL a los sitios protegidos con ellos recibiremos una advertencia de seguridad delnavegador, ya que el certificado no está emitido por una entidad de confianza reconocida. Esto es lógico sino el uso de certificados "de verdad" carecería de sentido, pues se perdería su objetivo principal que es la confianza, y pervertiríamos el concepto subyacente a las PKI.

No obstante, incluso en estas condiciones y aparte de su uso para pruebas y desarrollo, este tipo de certificados auto-firmados pueden ser muy útiles, ya que nos permiten conseguir el objetivo 2, es decir, el cifrado de las comunicaciones. Si por ejemplo tenemos algún trabajador que esporádicamente está de viaje y se quiere conectar al webmail o a una aplicación desde una red pública (un WiFi en una cafetería o centro comercial, por ejemplo) podemos utilizar uno de estos certificados para cifrar las comunicaciones y que las claves no viajen en claro y puedan ser interceptadas. No nos valida el servidor pero tampoco tenemos esto si nos conetcamos de forma "normal", por HTTP, y sería muy raro que alguien intentara suplantar justo a nuestro webmail usando envenanimiento de DNS en un centro comercial para engañar a un comercial nuestro y robarle las credenciales ¿no? ;-)

Es decir, ni se te ocurra usar esto para una aplicación de verdad ni para algo a lo que deban acceder muchos usuarios, pero para pruebas y para conexiones esporádicas a sistemas no críticos nos permitirá ahorrarnos un dinero y conseguir al menos el cifrado de datos en las conexiones, lo que no es poco.

Espero que te sirva :-)

El título es así de largo proque realmente trato varios temas que están relacionados yq ue a muchos programadores Web les pueden a resultar útiles.

Primeramente, pregunta típica: ¿puedo utilizar varios certificados SSL (Secure Sockets Layer) en un mismo servidor Internet Information Server (IIS)?

Respuesta: Sí y No.

Un servidor IIS 6.0 permite por defecto asignar varios certificados a servidores virtuales diferentes siempre y cuando éstos funcionen cada uno en un puerto distinto. Así, si usamos en alguno un puerto no estándar (distinto al 443), pues entonces sí nos deja, pero vamos, esto dista bastante de ser una buena solución. También nospermite tener dos certificados en dos servidores virtuales diferentes si cada uno de ellos utiliza una IP distinta. Tampoco es muy útil.

Si vamos al diálogo "Avanzadas" de la pestaña general de propiedades de un sitio Web de IIS, veremos que aunque en peticiones sin encriptar nos permite definir tantos encabezados de host como queramos en la misma IP y mismo puerto para así distinguir unas peticiones de otras, en el caso de SSL sólo nos deja indicar una IP y un puerto, sin posibilidad de distinguir encabezados de host:

Por este motivo, si en dos sitios Web utilizan la misma IP y el puerto estándar 443 y les asociamos un certificado de servidor para que cifren las ocmunicaciones con SSL, en cuanto lo hagamos con el segundo éste se nos parará. No nos dejará arrancarlo de nuevo porque nos dice que no puede haber dos servidores escuchando en el mismo puerto.

Si tuviésemos la posibilidad de distinguir las peticiones SSL por encabezado de host, como pasa en peticiones normales sin encriptar, entonces ya estaría el tema solucionado. El problema es que, por definición, la información viaja encriptada (incluyendo la petición y el encabezado de host) por lo que IIS no tiene manera de determinar ese encabezado de host hasta que lo desencripta en el servidor con el certificado adecuado. Es decir, que si antes no sabe qué certificado utilizar entonces no puede determinar el encabezado de host que tiene la petición, y viceversa. Es un típico problema recursivo que crea esta limitación. Antes de que algún anti-MS salte a la yugular diré, por si no está suficientemente claro aún con la explicación, que se trata de una limitación de SSL no de IIS. Le pasa a todos los servidores web.

Entonces ¿cómo solucionamos el asunto?

Bueno, la conclusión es que sólo podremos distinguir entre unas peticiones y otras si usamos para todas ellas el mismo certificado. Pero por definición cada sitio web (con un dominio distinto) tiene que tener un certificado diferente, o entonces podríamos desencriptar pero fallaría la autenticaicón del servidor pues no se correspondería con el dominio (¿me explico?). Por lo tanto la única solución es que todos esos dominios que queremos proteger deben tener el mismo dominio o subdominio principal, y debemos asignar al servidor un certificado comodín, es decir, uno que sirva para proteger un dominio y todos sus subdominios.

Así, podremos proteger con un mismo certificado comodín por ejemplo a los dominios: shop.campusmvp.com, www.campusmvp.com y aulas.campusmvp.com, o cualesquiera otros que compartan un mismo sufijo en el dominio. El certificado que usemos debe certificar al dominio comodín: *.campusmvp.com.

Estos certificados comodín los tenemos que pedir expresamente a nuestro proveedor de certificados (Thawte, verisign, Camaras.org o quien sea). Generalmente son bastante más caros que los normales puesto que, realmente, les estás fastidiando el negocio porque con un solo certificado proteges varios dominios, así que se aseguran unas ganacias penalizándote el precio.

Si tienes que proteger varios dominios distintos no te quedará más remedio que asignarle una IP diferente a cada uno. Efectos secundarios de la seguridad ;-)

Asignación de encabezados de host a cada subdominio

Vale. supongamos entonces que quieresproteger varios subdominios con un certificado comodín. Según he dicho antes no vamos a poder de todos modos establecer el encabezado de host porque la herramienta de administración de IIS no nos lo permite. Entonces ¿cómo lo hacemos?

El proceso es el siguiente. Instalas el certificado en el primero de los dominios y le asignas el puerto 443 a la IP que le corresponda. Ahora debes usar una herramienta de script administrativo de IIS para establecer el encabezado. Abres una línea de comandos, vas hasta la carpeta de scipts administrativos (por defecto C:\InetPub\AdminScripts) y escribes lo siguiente:

cscript.exe adsutil.vbs set /w3svc/<ID del servidor virtual>/SecureBindings ":443:subdominio.dominio.com"

Por ejemplo:

cscript.exe adsutil.vbs set /w3svc/1669802537/SecureBindings ":443:mcs.krasis.es"

Vale. Primera dificultad: hay que averiguar cuál es el identificador de nuestro servidor virtual :-?

Para ello tienes que irte a la metabase de IIS y buscarlo entre todo ese infernal XML :-( Así que mucho mejor vamos a usar una herramienta que lo haga por nosotros. Si te descargas el Resource Kit de IIS 6.0, dentro del mismo hay una herramienta llamada IIS Metabase Explorer que te permite hacer lo que su nombre indica: bucear en la metabase sin tener que lidiar directamente con ella. Instálala y podrás averiguar fácilmente el identificador de tu servidor virtual viéndolo en el nodo correspondiente de la rama LM\W3SVC, como en esta figura:

Pulsa para aumentar

Con esto es coser y cantar pues sólo tienes que copiar el "numerito" y ya podrás asignarle el certificado al subdominio (o subdominios) que necesites.

Ahora sólo resta repetir la misma operación en el resto de subdominios/servidores virtuales y listo.

Espero que esto le resulte útil a mucha gente.

En el próximo post voy a comentar algo muy interesante relacionado con este tema: cómo crear y asignar automáticamente certificados SSL a nuestros dominios creados y firmados por nosotros mismos para pruebas o para uso privado. Y lo mejor: sin tener que instalar ningún tipo de infraestructura PKI (Infraestructura de clave pública) y con un simple programita de línea de comandos :-)

Las páginas ASPX funcionan mediante la inclusión de un formulario único que contiene todo los controles de la página y que, al enviarlo, actualiza ciertos parámetros para mantener el ViewState, saber qué control ha provocado un evento, etc... El funcionamiento basado en un formulario provoca algunos comportamientos indeseados.

Por ejemplo, los cuadros de texto, por defecto, cuando tienen el foco (porque estás escribiendo en ellos) provocan el envío automático del formulario si pulsas ENTER. Si tienes el típico cuadro de búsqueda con un botón o un formulario de recogida de datos con un botón de enviar, al pulsar ENTER conseguirás que se envíe la página pero al no haber pulsado sobre el botón no se detectará el evento correspondiente y por lo tanto no se ejecutará el código del eento click de éste. El resultado es que no se actualiza correctamente la página y simplemente volvemos a tener la misma página exactamente igual y la búsqueda no funciona o los datos no se almacenan.

Seguro que te ha pasado muchas veces al visitar aplicaciones hechas con ASP.NET. De hecho es una de las típicas preguntas que le surgen a todo el mundo: ¿cómo evito esto?

En ASP.NET 1.x tenías que capturar con JavaScript el evento de pulsación de la tecla y actuar en consecuencia. Por suerte desdela versión 2.0 de ASP.NET (y posteriores), tenemos una propiedad estupenda que se puede ajustar en el formulario de la página llamada DefaultButton y que sirve precisamente para evitar este problema.

Así, si ponemos esto:

<form id="Form1" runat="server" defaultbutton="cmdBuscar">

conseguiremos que alel hecho de pulsar ENTER y provocar un envío del formulario, en realidad será equivalente a pulsar el botón indicado. De este modo se evita el problema por completo y podemos procesar correctamente el evento :-)

Por cierto, en la versión 2.0 también apareció una propiedad del formulario relacionada en cierto modo con esta y útil para no tener que scribir un sencillo script por nuestra parte: DefaultFocus. Como se puede esperar esta propiedad nos permite indicar qué control de los disponibles en nuestra página va a tener el foco al cargar la página (generalmente un cuadro de texto).

¡Espero que os sea útil!

Cualquier programador .NET que se precie conoce, usa constantemente y adora la herramienta Reflector de Lutz Roeder. se trata sin duda de una de las herramientas más potentes y útiles con las que podemos contar. Lo que habré aprendido yo usándola :-)

El caso es que Reflector ha sido siempre el proyecto personal del bueno de Lutz, que lo ponía disposición de todo el mundo gratuitamente en su Web, para el bien de la humanidad. El hecho de no cobrar un duro es digno de admirar pues, desde mi punto de vista, Lutz podría ser multimillonario si se le diera por cobrar aunque fuera únicamente 4 o 5 euros por cada descarga. Yo pagaría sin duda unos cuantos más si los pidiera. Pero hasta ahora eso no ha ocurrido.

Por este motivo me sobresalté al recibir esta misma noche un correo electrónico de Lutz en el que anunciaba que había llegado un acuerdo con la empresa Redgate, muy conocida sobre todo por sus excelentes herramientas para SQL server, en virtud del cual esta empresa pasaba a poseer la herramienta (de hecho la URL original ya apunta a la web de Redgate como puedes comprobar) y a comprometerse a desarrollarla en el futuro. ¡ding, ding, ding! Todas las alarmas en marcha. Lo que parecía inevitable iba a pasar...

Pues parece ser que no. Según afirman en la propia Web de Redgate así como en una entrevista conjunta concedida por ambas partes la semana pasada, el acuerdo contempla que la herramienta siga siendo gratuita para siempre. Simplemente Redgate le dedicará los recursos que Lutz no puede dedicarle y no cobrará por ello. Obviamente ninguna empresa da nada totalmente gratis o al menos sin una contraprestación (aunque los apóstoles más ingenuos del Open source afirmen que sí y crean que depredadores tan reconocidos como Oracle, IBM o Sun son hermanitas de la Caridad y no que responden simplemente a una estrategia empresarial). En este caso me imagino que la contraprestación es la ingente publicidad gratuita y reconocimiento de marca que va a obtener Redgate con ello, lo cual me parece muy lícito.

De hecho se lo han hecho tan bien que Lutz afirma que no les ha facilitado la base de datos de correos electrónicos de usuarios de reflector que posee (que debe de ser gigantesca), y sólo recibirás correo de Redgate si te suscribes voluntariamente a su boletín, lo que es una estupenda buena práctica. Este hecho además tiene su valor especial al tratarse de EEUU un país con una regulación más laxa que la de Europa en cuanto a protección de datos (vamos, que no tendrían por qué hacerlo).

Así que ¡Chapeau por ellos! y creo que es un agran noticia para todos.

El otro día os hablaba de un problemilla con un NAS que tenemos y alguno me ha comentado que cómo podía hacer para lanzar la línea de comandos ya que este tipo de sistema vienen completamente cerrados a cal y canto. Voy a explicar cómo hackearlo y veremos que esta es la prueba evidente de que cualquier chorrada por pequeña que sea puede ser un agujero de seguridad.

Resulta que en efecto el NAS viene completamente "capado". Lleva Windows XP Embedded y te deja acceder a través de Terminal Server pero te saca una interfaz muy restringida de administración que la verdad no merece la pena puesto que desde la interfaz web que trae se pueden hacer más cosas aún. Esta interfaz reducida tiene el aspecto de una página Web y es en realidad una pequeña aplicación ejecutable que es lo único que se ejecuta al arrancar. no tienes acceso a minimizarla, ni al escritorio, ni responde a las teclas rápidas de sacar el explorador (Windows + E), ni nada similar. Pero sí hay una tecla rápida que responde: CTRL + MAYUSCULAS + ESC, es decir, que puedes sacar el administrador de tareas. Con esto todo parece fácil ya, porque va a Archivo·Ejecutar y listo ¿no?. Pues no. Resulta que el administrador de tareas viene también "capado" y no te deja ejecutar nada:

Pulsa para aumentar

O sea, que por aquí vamos mal ¿o no?. Pues puede que no. Y es aquí en donde se demuestra lo de que cualquier minucia puede ser un problema y que los agujeros aparecen en el lugar más insospechado. Si vas a Ayuda·Acerca de aparece un diálogo con información y un enlace para leer el contrato de licencia, que es un simple archivo TXT. El problema es que han querido "capar" tanto el sistema que ni siquiera trae las asociaciones de archivos con los programas, por lo que cuando pulsas en el enlace para leer la licencia pasa esto:

Pulsa para aumentar

Así que a partir de este momento el sistema es nuestro. Al darle a seleccionar el programa desde una lista se nos abre un diálogo de selección de un programa. El único disponible es Internet Explorer que parece el único que está registrado, pero tenemos el botón de explorar, lo que nos abre un diálogo común de apertura de archivos:

Pulsa para aumentar

Ahora ya sólo queda pulsar con el botón derecho en cualquier parte y elegir la opción de "explorar" y voilá!, se nos abre un explorador de archivos en toda su capacidad:

Ahora sólo resta navegar a Windows\System32 y lanzar la línea de comandos o cualquier otra aplicación que nos interese dado que el login por Terminal Server lo has hecho como administrador.

Es una chorrada pero demuestra lo fácil que es saltarse muchas protecciones y además seguramente os servirá para otro tipo de dispositivos que tengan alguna versión de Windows wmbebida :-)

Borrar carpetas o archivos puede parecer una trivialidad y lo es en la mayoría de los casos. Como casi todo en la vida la cosa se complica con los grandes números. Si tenemos que borrar una gran carpeta con miles de archivos y muchos gigas de tamaño la cosa llevará tiempo y además se necesita tener bastante espacio libre en disco para hacerlo (el porqué de esto lo desconozco. Parece una paradoja pero es así).

Hoy me he encontrado en un atolladero así. Un pequeño NAS que tenemos en el DataCenter para hacer algunas copias de seguridad estaba repleto. En una carpeta conflictiva en concreto había unas 150 subcarpetas cada una de ellas con varios gigas, y miles de archivos y una estructura compleja de varias decenas de subcarpetas. Necesitaba borrar la mayor parte de ellas para hacer espacio (ya no se necesitaban) pero no lo podía conseguir desde el explorador de Windows. El proceso de todas formas iba a durar mucho tiempo. ¿Cómo puedo automatizar esto? El mayor problema además es que no tenía que borrar todas sino "casi" todas. En informática los "casi" son siempre los que suponen un reto ¿no? :-)

Bueno, la solución más rápida y sencilla fue usar la línea de comandos. Ábrela y vete a la carpeta en la que quieres trabajar.

Lo primero es crear un archivo de texto con la lista de subcarpetas dentro de mi carpeta problemática. Necesitaba sólo los nombres de los archivos, sin nada más. El comando necesario es este:

dir /ad /b > carpetas.txt

De este modo creamos un archivo carpetas.txt que contendrá los nombres de todas las carpetas de la carpeta actual.

Ahora abre el archivo de texto y borra los nombres de las carpetas que quieres conservar. Con esto consigues una lista de carpetas a borrar. Ahora sólo necesitas iterar por ellas en un bucle eliminándolas, para lo que sólo tienes que escribir esto en la línea de comandos:

For /f "delims=" %n in (carpetas.txt) do rmdir /s /q "%n"

¡Listo! Tardará un montón también si hay muchas carpetas y son muy grandes, pero te hará el trabajo sin poner mucho de tu parte y de manera mucho más eficiente que usando la línea de comandos y siendo mucho más selectivo sobre lo que vas a borrar.

Yo, como es evidente, no soy especialista en sistemas ni mucho menos, así que espero que esto le sirva a otros que tampoco lo sean y a veces "les toque" :-)

Nota: si quieres usar la última línea dentro de un archivo .bat y no directamente sobre la línea de comandos deberás usar doble porcentaje en lugar de uno simple para el nombre de la variable de bucle, así:

For /f "delims=" %%n in (carpetas.txt) do rmdir /s /q "%%n"

o de otro modo no te funcionará.

Una de las mejoras sencillas y poco llamativas en primera instancia que ha incluido el Service Pack 1 de .NET 3.5 y Visual Studio 2008 es la consolidación de Scripts. Sin embargo es algo interesante que conviene conocer.

Se trata básicamente de evitar que el navegador tenga que descargar multitud de pequeños archivos de Script desde el servidor, sustituyéndolos de manera automática por una sola descarga combonada, que es más eficiente y rápida como demostraré enseguida.

Es la típica característica que va a pasar inadvertida para la mayoría de los programadores Web pero que es interesante, y por eso me ha apetecido contarla en detalle aquí. Para ello he desarrollado un ejemplo muy simple pero que da una idea de la utilidad de esta característica. En el siguiente vídeo muestro cómo funciona la consolidación de Scripts mediante las nuevas etiquetas CompositeScript. También muestro un control desconocido pero interesante y pensado para ayudarnos a trabajar con esta característica: el control ScriptReferenceProfiler.

Si no ves bien el vídeo pulsa aquí

Este vídeo es como los muchos que puedes encontrar, junto con la teoría correspondiente, en cualquiera de nuestros cursos online de campusMVP sobre tecnología Microsoft, sólo que en los cursos los vídeos son de mejor calidad porque no nos limitan los tamaños de SoapBox, YouTube y similares :-)

¡Espero que os interese!