Archivo de la etiqueta: iis

Optimizar cache en IIS

En este post aprenderemos a optimizar cache en IIS editando el web.config.

Si tu servidor de alojamiento web es IIS puedes mejorar la velocidad de tu sitio estableciendo el tiempo de la caché insertando dentro de <system.webServer> del archivo web.config de la raíz de tu aplicación web:

<staticContent>
<clientCache cacheControlMode=”UseMaxAge” cacheControlMaxAge=”7.00:00:00″ />
</staticContent>

Donde cacheControlMode puede tomar los valores:

  • “NoControl”: no se establece un tipo de caché para el sitio, con lo que tomará los valores globales de configuración heredados.
  • “DisableCache”: caché deshabilitada para el sitio.
  • UseMaxAge: se especifica una edad de expiración de la caché en el parámetro cacheControlMaxAge en días, horas, minutos y segundos (d.hh:mm:ss)
  • UserExpires: indica la fecha exacta de expiración de la caché.
Optimizar cache en IIS
Valora este artículo

Problemas con OWIN en un hosting compartido

Si vas a desarrollar una aplicación asp.net con OWIN y piensas alojarla en un servidor compartido debes tener esto en cuenta.

En muchos proveedores de hosting compartido tienen configurado en IIS el nivel de confianza high, medium, low… pero no está “Full”.

Esto es importante porque los ensamblados OWIN necesitan para su perfecta ejecución el nivel de confianza Full. (trust level=”Full”). Este parámetro se puede configurar en el web.config pero será inútil ponerlo si a nivel de máquina el machine.config no permita sobrescribirlo.

trust_level

Los problemas con OWIN en un hosting compartido parten de que OWIN utiliza reflection para instanciar algunos objetos y la seguridad del servidor no lo permite.

Existen varias soluciones, pero todas pasan por contratar otro tipo de hosting:

  • Servidor Virtual, quizá la más económica priori.
  • Azure, se paga por recursos utilizados y es altamente escalable.
  • Servidor dedicado, seguro la menos económica.
Problemas con OWIN en un hosting compartido
Valora este artículo

OWIN: Otra novedad en Visual Studio 2013

Open Web Interface for .NET (OWIN) define una nueva capa de abstración entre el servidor web y una aplicación web. De este modo OWIN permite a las aplicaciones que no les importe en que host esté hospedado. Por ejemplo una aplicación web se puede hospedar en IIS o en un proceso personalizado.

Esta tecnología se conoce también como el proyecto Katana y se inspira en otras tecnologías del estilo node.js.

El problema que intenta solucionar OWIN es desacoplar la dependencia que tenían las aplicaciones ASP.Net con el servidor IIS introduciendo una capa que maneje las peticiones Http.

Sin Open Web Interface for .Net:

Sin OWIN

Con Open Web Interface for .Net:

Con OWIN

OWIN: Otra novedad en Visual Studio 2013
Valora este artículo

Autorización de urls en ASP.NET

La autorización de ASP.NET permite controlar el acceso a los recursos por parte de un usuario autenticado. Es decir podemos establecer si un usuario o grupo de usuarios tendrá posibilidad de acceder a una url en concreto.

Para ello se pueden establecer por cada directorio o archivo los permisos necesarios para acceder a él.

Todos sabemos que se pueden establecer reglas de reescritura mediante un web.config. A mi parecer la autorización de urls en asp.net está mal llamado por Microsoft porque lo que en realidad se controla es el acceso a un fichero o directorio determinado (es decir un recurso físico, no urls como tal).

Para establecer permisos en un sitio web se utilizarán los ficheros de configuración web.config. A continuación vamos a introducir algunos ejemplos que indican el funcionamiento de la autorización de urls en ASP.NET.

  • Denegar usuarios anónimos a toda la web. En el web.config del sitio:

<system.web>

...
	<authorization>
		<deny users="?"/> //acceso denegado a usuarios anónimos
	</authorization>

</system.web> 

  • Acceso denegado a usuarios anónimos pero posibilidad de acceso de uno a una página determinada

...

<configuration>

	<system.web>
	
		<authorization> 
			<deny users="?"/>  //restringir usuarios anónimos
		</authorization>
		
	</system.web>

	<location path="registro.aspx"> //página a la que se aplicarán las siguientes configuraciones

		<system.web>

			<authorization>
				<allow users="*"/> // esto permitirá el acceso a cualquier usuario anónimo
			</authorization>

		</system.web>

	</location>

</configuration> 

  • Dar permiso a un usuario en concreto y denegar a todos los demás:

<location path="usuario_con_privilegios.aspx">

    <system.web>

        <authorization>

			<allow users="premium"/> // acceso permitido a usuario_premium
			<deny users="*"/>  // acceso denegado a todos los demás

        </authorization>

    </system.web>

</location>

 


  • Permitir a usuarios con un determinado rol

<location path="DirectorioAdmin">

    <system.web>
		<authorization>

			<allow roles="Admin"/> //Acceso permitido para usuarios con rol Admin
			<deny users="*"/> // Acceso denegado a todos los demás

		</authorization>
    </system.web>

</location>

<location path="CustomerFolder">

    <system.web>
		<authorization>

			<allow roles="Admin, Clientes"/> //Acceso permitido a usuarios con roles admin o clientes
			<deny users="*"/> // Acceso denegado a todos los demás

		</authorization>
    </system.web>

</location>

  • Es posible también establecer reglas en un web.config por cada directorio. Es decir tener un fichero web.config para cada directorio.

<configuration>

    <system.web>

        <authorization>
			<allow roles="Admin"/> //Acceso permitido a usuarios con el rol Admin
			<deny users="*"/> // prohibir acceso a todos los demás
        </authorization>

    </system.web>

</configuration> 

Reglas

Hay que tener en cuenta de cómo se aplican las reglas:

  • Las reglas contenidas en archivos de configuración en la aplicación tienen prioridad sobre las reglas heredadas. El sistema determina la regla que tiene prioridad creando una lista combinada de todas las reglas de una dirección URL, con las reglas más recientes (más arriba en la jerarquía) al principio de la lista.
  • Dado un conjunto de reglas combinadas para una aplicación, ASP.NET comienza al principio de la lista y comprueba las reglas hasta que encuentra la primera coincidencia <allow users=”*”/> que autoriza a todos los usuarios. (Esta regla se aplica en último lugar de forma predeterminada.) Si no coincide ninguna otra regla de autorización, se permite la solicitud. Si se encuentra una coincidencia y ésta es un elemento deny, la solicitud se devuelve con el código de estado 401 HTTP. Si coincide un elemento allow, el módulo permite que se siga procesando la solicitud.
Autorización de urls en ASP.NET
Valora este artículo

Autenticación en ASP.NET con IIS

Autenticación es el acto de validar la identidad de un cliente. Una vez autenticado un cliente podemos controlar el acceso de este cliente a los recursos. Para autenticarse, el cliente debe establecer unas credenciales (usuario y contraseña) que indique unívocamente quien es.

En ASP.NET existen estos tipos de autenticaciones:

  • Autenticación Windows, utiliza servicios propios del sistema operativo, de usuarios del sistema o incluso de red (directorio activo).
  • Autenticación basada en formularios, a través de un formulario de acceso se gestiona el inicio de sesión y la autenticación de un cliente. Es uno de los métodos de autenticación más comunes ya que para aplicaciones que requieran de autenticación en Internet no es lógico utilizar la autenticación Windows.
  • Passport, sirve para utilizar un único inicio de sesión en varios dominios. Es decir es parecido a lo que utiliza Google para todos sus servicios, cuando estas autenticado en un servicio puedes acceder a otro sin tener que dar tus credenciales de nuevo.
Autenticación Windows

Dentro de la autenticación Windows a su vez se encuentran estos subtipos:

  • Anónima, no se le pide directamente al cliente ningún tipo de credenciales.
  • Básica, el navegador solicita al cliente el usuario y contraseña. De manera predeterminada la cuenta enviada debe tener privilegios de inicio de sesión en el servidor web. Es decir es como si nos autenticaramos directamente en el servidor web. Este método de autenticación no es muy seguro ya que se envía mediante http y el método de codificación de la información es relativamente fácil revertirlo.
  • Implícita, es similar a la autenticación básica pero el algoritmo que codifica la información por http es más seguro. Mientras que la autenticación básica utiliza Base64 la autenticación implícita utiliza un digest o hash que es mucho más segura.
  • Autenticación de Windows Integrada, la autenticación de Windows integrada es la mejor opción cuando se utiliza una aplicación web de intranet donde los usuarios tienen cuentas de dominio de Windows. En estos casos la autenticación se realiza automáticamente sin que el cliente tenga que introducir sus credenciales.
  • Autenticación mediante certificados de cliente, un certificado es una instrucción que contiene información sobre una entidad y su clave pública en un grupo. Los certificados pueden contener aparte otros datos. 
Autenticación en ASP.NET con IIS
Valora este artículo

Usar la reescritura URL en joomla! editando el web.config en IIS

Como sabréis las palabras contenidas en las direcciones URL son importantes para los buscadores a la hora del posicionamiento. Por ello es mucho más optimo tener una url del tipo:

http://posicionamiento-sitios-web.blogspot.com.es/mis-palabras-clave

que otra como la siguiente

http://posicionamiento-sitios-web.blogspot.com.es/index.php?article-id=4

Hay que aprovecharse de esto y “pasar” algunas palabras clave en cada una de las URL de nuestro sitio.

La mayor parte de los CMS que podemos utilizar actualmente están preparados para mejorar el posicionamiento orgánico. Entre estos CMS está joomla!.

Si tu servidor web es IIS con el módulo URL rewrite y tienes un sitio web en joomla! deberás editar el archivo web.config en la raíz de tu aplicación. En el apartado <system.webServer> inserta el siguiente bloque XML:


<rewrite>

<rules>

<rule name="Joomla! Rule 1" stopProcessing="true">

<match url="^(.*)$" ignoreCase="false" />

<conditions logicalGrouping="MatchAny">

<add input="{QUERY_STRING}" pattern="base64_encode[^(]*\([^)]*\)" ignoreCase="false" />

<add input="{QUERY_STRING}" pattern="(&gt;|%3C)([^s]*s)+cript.*(&lt;|%3E)" />

<add input="{QUERY_STRING}" pattern="GLOBALS(=|\[|\%[0-9A-Z]{0,2})" ignoreCase="false" />

<add input="{QUERY_STRING}" pattern="_REQUEST(=|\[|\%[0-9A-Z]{0,2})" ignoreCase="false" />

</conditions>

<action type="CustomResponse" url="index.php" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />

</rule>

<rule name="Joomla! Rule 2">

<match url="(.*)" ignoreCase="false" />

<conditions logicalGrouping="MatchAll">

<add input="{URL}" pattern="^/index.php" ignoreCase="true" negate="true" />

<add input="{URL}" pattern="/component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$" />

<add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" />

<add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" />

</conditions>

<action type="Rewrite" url="index.php" />

</rule>

</rules>

</rewrite>

Con esto IIS puede aprovechar unos patrones de expresiones regulares para convertir peticiones y transformarlas a urls con alias

Usar la reescritura URL en joomla! editando el web.config en IIS
Valora este artículo

Últimas tecnologías Web

Muchas tecnologías avanzan vertiginosamente hacia un futuro que seguramente no podamos ni imaginar. Este mismo futuro no nos permite ni un solo descanso y nos obliga a seguir aprendiendo. En el área del desarrollo y programación web pasa lo mismo.

Cada cierto tiempo los lenguajes de programación como ASP.Net, PHP, silverlight, etc. realizan cambios y mejoras en su framework aumentando, refinando y adaptando su funcionalidad y, al mismo tiempo, dejando poco a poco obsoletas versiones anteriores.

Por eso es recomendable utilizar las últimas tecnologías al servicio de los clientes. Tecnologías Web:

  • Web 2.0 – jQuery, XHTML, HTML5, AJAX
  • PHP 5.x
  • .Net 4.0 y .Net 4.5 – ASP.Net, Silverlight, Web Services, WCF, Entity Framework
  • CMS – Joomla! 2.5, joomla! 3.0, Drupal 7, WordPress 3.x
  • Datos y SGDB – SqlServer, Oracle, MySql, Pervasive, ODBC, XML, csv…
  • Servidores Web – IIS 6, IIS 7 y Apache.

Si lo prefiere para posibles mantenimientos de antiguos sitios web también tengo amplia experiencia en las versiones anteriores de PHP, ASP Clásico, ASP.Net (1.0, 2.0, 3.0 y 3.5) y joomla 1.6

Últimas tecnologías Web
Valora este artículo

Handler axd funciona correctamente en local pero no funciona en el servidor

Tengo una librería MSCaptcha que funciona correctamente en local pero al subir al servidor no funciona correctamente.

El problema surge de que IIS7 introdujo dos condiciones previas denominadas integratedMode” y “classicMode. Un handler que tiene una precondition integratedMode asociado a él sólo se puede cargar en un grupo de aplicaciones que tiene el integratedMode establecido en el conjunto de propiedades en la ApplicationPool. Handlers con la precondition classicMode sólo se cargarán en Grupos de aplicaciones que tienen la propiedad integratedMode establecida en falso.

En mi servidor local el pool de aplicaciones está en modo integrado con lo que la librería MSCaptcha funciona correctament pero en el servidor de producción está en modo clásico.

Para solucionarlo sin tener que cambiar configuraciones de servidor se puede establecer en el web.config una directiva para que el handler cargue con la configuración que decidamos.

En mi caso particular será:


<add name="MSCaptcha" verb="GET" path="CaptchaImage.axd" type="MSCaptcha.CaptchaImageHandler, MSCaptcha" preCondition="integratedMode"/>

De está forma he logrado que mi captcha se visualiza en el servidor.

Handler axd funciona correctamente en local pero no funciona en el servidor
Valora este artículo