Archivo por meses: enero 2014

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.

Redireccionar url en función del navegador en Apache

En ocasiones es necesario añadir reglas de redireccionamiento dependiendo el navegador que utilice nuestro cliente web.

Para ello podemos utilizar el archivo .htaccess e indicar unas directivas en función del navegador que se esté utilizando el cliente.

El siguiente bloque escrito en htaccess puede ser muy útil si tienes sitios que no se muestran correctamente en navegadores viejos y obsoletos:


<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} "MSIE 8" [or]
RewriteCond %{HTTP_USER_AGENT} "MSIE 7" [or]
RewriteCond %{HTTP_USER_AGENT} "MSIE 6"

RewriteRule . actualizar-navegador.html [L]

Con esto le estamos diciendo que si el navegador del cliente en Internet Explorer 6, 7 u 8 vaya a una página especial donde le podremos indicar al usuario que necesita actualizar el navegador.


<!DOCTYPE html>

<body>

<div>

...

necesita actualizar el navegador para visualizar correctamente la página, para ello visite los siguientes links...

</div>

</body>

</html>

Redireccionar url en función del navegador en Apache permite también ocultar el acceso a ciertos navegadores. Esto puede ser útil en empresas que tienen intranets y obligan a sus empleados a utilizar un único navegador por seguridad.

Diferencias entre autenticación y autorización

En muchas ocasiones no se llega a distinguir las palabras o términos que más se utilizan en el mundo del software o Internet.

Un ejemplo podría ser las diferencias entre autenticación y autorización que son fundamentales en el desarrollo del software.

  • La autenticación es el proceso por el cual se identifica un cliente (persona) como válida para posteriormente acceder a ciertos recursos definidos.
  • La autorización es el proceso sobre el cual se establecen que tipos de recursos están permitidos o denegados para cierto usuario o grupo de usuarios concreto.

Podríamos poner un ejemplo de un usuario que se autentifique (identificado) en una aplicación pero que no tenga acceso a ningún recurso porque no está autorizado a ello. Esto sería como que tu presentaras tus credenciales en un sitio web y al acceder a tu panel de administración no podrías realizar ninguna acción. En realidad este caso sería un caso poco realista pero serviría para explicar cual es la diferencia entre autenticación y autorización.

La autorización tiene mucho que ver con perfiles y roles de usuarios. Lo normal es que al diseñar una aplicación existan muchos tipos de usuario que englobemos en distintos perfiles: por ejemplo: administrador, editor, invitado…

Estos usuarios tendrán acceso a distintos recursos según sea el perfil al que pertenezcan. Un administrador de un sistema, por ejemplo, tendrá acceso a todos los recursos que ofrezca la aplicación. Hablamos de recursos como todos los recursos, no solamente los contenidos sino también ficheros, servicios, etc. que se encuentren en el servidor web o incluso fuera de él.

Existen hasta modos de establecer que nivel de autorización tiene un usuario que no está autenticado, es decir, un invitado de un sitio web a veces puede tener acceso a muchos pero no todos los recursos.

Diferenciar estos dos conceptos es importante para un desarrollador sobretodo a la hora de buscar documentación.

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. 

Conocer ruta logs y tmp del servidor en producción

Si el desarrollo de tu sitio web joomla! lo has realizado en tu equipo local puede ser que en el momento de subirlo a producción tus rutas hacia las carpetas logs y tmp no sean las correctas.

Para averiguar la nueva ruta física completa donde se encuentran dichos directorios puedes crearte un nuevo fichero php como por ejemplo ruta.php con el siguiente código:

<?php echo __FILE__; ?>

Este fichero le colocarás por ejemplo en la raíz de tu directorio html de tu servidor hosting mediante ftp y posteriormente accederás a la ruta del tipo:

www.nombredetudominio.es/ruta.php

En la pantalla del navegador podrás visualizar la ruta física que utilizarás para configurar las rutas hacia las carpetas logs y tmp editable desde la opción de menú configuración global o directamente sobre el archivo configuration.php de tu sitio joomla!

En la comprobación que permite joomla! se establecen entre otras cosas la ruta logs y tmp del servidor marcando como erróneo cuando estas no tienen los permisos suficientes.

Manejo y registro de errores php en tiempo de ejecución

Es posible que al ejecutar un sitio web php con apache aparezcan en pantalla errores de tipo notice, warning, error…

El modo en que se muestran o advierten al usuario es lógicamente administrable a través de sus ficheros de configuración.

Antes de nada hay que aclarar que php ofrece distintos niveles de manejo de errores y logging.

Las constantes de nivel de errores

Los niveles de error en php son:

  • E_ALL: todos lo errores y advertencia.
  • E_ERROR: errores fatales en tiempo de ejecución.
  • E_RECOVERABLE_ERROR:  errores en tiempo de ejecución capturable. Si no se captura pasa a ser de tipo E_ERROR.
  • E_WARNING: advertencias en tiempo de ejecución. (no son errores fatales).
  • E_PARSE: errores en tiempo de compilación.
  • E_NOTICE: avisos en tiempo de ejecución (son advertencias que suelen derivar de bugs en el código, pero que son posiblemente intencionados).
  • E_STRICT: avisos en tiempo de ejecución para que php sugiera cambios en el código para asegurar compatibilidad con dicho código
  • E_CORE_ERROR: errores fatales que ocurren durante la inicialización de php.
  • E_CORE_WARNING: advertencias que ocurren durante el arranque de php.
  • E_COMPILE_ERROR: errores fatales en tiempo de compilación.
  • E_COMPILE_WARNING: advertencias en tiempo de compilación.
  • E_USER_ERROR: mensajes de error generados por el usuario mediante el código.
  • E_USER_WARNING: mensajes de advertencia creados por el usuario.
  • E_USER_NOTICE: mensajes de aviso creados por el usuario por código.
  • E_DEPRECATED: aviso sobre una parte de código que no será funcional en versiones futuras de php.
  • E_USER_DEPRECATED: aviso generado por el usuario que no será funcional en posteriores versiones de php.

Estos errores se mostrarán o no dependiendo de la configuración de php.ini. Este fichero se encuentra en la instalación típica de php dentro de Apache.

Los parámetros más importantes que se utilizan para configurar el manejo de errores  y logs son:

  • error_reporting
  • display_errors

Con error_reporting podemos establecer qué nivel o niveles de errores se mostrarán de todos los que hemos expuesto anteriormente.

Los valores más comunes para la configuración de este parámetro son:

  • Valor por defecto en la mayor parte de instalaciones:
error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE
  • Valor idóneo para etapas de desarrollo:
error_reporting=E_ALL
  • Valor sugerido para producción:
error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT

Con la directiva display_errors podemos decidir si queremos que los errores se muestren en las páginas (en forma de html) a la hora de visualizar el resultado de nuestro código php. Esto puede ser muy útil cuando se trabaja en local o en proyectos que aún no están subidos a producción pero es totalmente indeseable cuando la web está desplegada en producción. Elegir una de las dos:

display_errors=On; Esta configuración mejor en desarrollo
display_errors=Off ; Esta configuración en producción

Configurar Virtual Host con Apache en Windows

Al montar Apache en Windows puede ser que te encuentres con el problema de descargar un sitio web que funciona correctamente en el servidor pero que al ejecutarlo en local (aunque sí que cargue) pierde estilos, enlaces, javascript y más cosas. Es posible que las rutas que utiliza ese código sean rutas relativas y al situarlo físicamente en tu workspace deje de funcionar.

La solución a este problema tiene un nombre: Virtual Hosts. Con este módulo se permite configurar múltiples sitios dentro de un mismo servidor dándoles los nombres que deseemos.

Existen numerosas formas de configuraciones de virtual hosts en Apache, yo trataré en este post de explicar la forma más común de configuración que consiste en crear varios hosts virtuales dentro de una misma dirección IP. (Si deseas más información puedes acceder a la página de documentación de Apache donde existen numerosos ejemplos).

Comencemos por editar el archivo de configuración de apache httpd-vhosts.conf. Este fichero se encuentra dentro de la ruta donde tengas instalado Apache dentro de la ruta apache\conf\extra. 


<VirtualHost *:80>
DocumentRoot "C:/xampp/htdocs/ejemplo1.com"
ServerName ejemplo1.com</VirtualHost>

<VirtualHost *:80>
DocumentRoot "C:/xampp/htdocs/ejemplo2.com"
ServerName ejemplo2.com

</VirtualHost>

...

Hasta este punto tendremos configurado Apache para albergar diversos sitios web con distinto nombre dentro de este servidor. Nos falta un segundo paso que nos permitirá que cuando introduzcamos en el navegador el nombre de uno de los sitios locales no se vaya a Internet a buscarlos sino a la ruta que nosotros le hemos establecido.

  • Ir a c:\windows\system32\drivers\etc\ y editar con el bloc de notas el archivo hosts
  • Insertar al final:

127.0.0.1 localhost
127.0.0.1 ejemplo1.com

127.0.0.2 ejemplo1.com

Escribiremos tantas líneas con los nombres de sitio como queramos acceder localmente.

Ahora solamente deberás abrir el navegador y meter la url que has establecido como servername, por ejemplo: local.ejemplo1.com 

cannot modify header information

Si se produce el siguiente error en PHP:
PHP Warning: Cannot modify header information – headers already sent by

Asegurate de que el fichero que te está produciendo el error no está enviando código html al servidor. Esto quiere decir que hay que tener mucho cuidado con todo, no solo los echo sino también espacios en blanco que el intérprete php pueda considerar código html.

Este error se suele producirse con relativa asiduidad cuando desde el código hacemos un


...

<html>
<?php
/* Esto producirá un error. Fíjese en el html
* que se muestra antes que la llamada a header() */
header('Location: http://www.example.com/');
exit;
?>

...

Centrar menu en Foundation

Este post indicará la manera de como centrar menu en Foundation.
Por defecto Foundation no permite centrar un menú en su framework.
Tenemos el siguiente marcado html:

<nav id="mi_menu" data-topbar="">
<ul>
<ul>
<ul><!-- Title Area --></ul>
</ul>
</ul>
<!-- Remove the class "menu-icon" to get rid of menu icon. Take out "Menu" to just have icon alone -->
<ul>
	<li><a><span>Menu</span></a></li>
</ul>
<section>
<ul>
	<li><a href="#">HOME</a></li>
	<li><a href="#" target="_blank">BLOG</a></li>
	<li><a href="#" target="_blank">SHOP</a></li>
</ul>
</section></nav>

Para centrar el menú podemos utilizar el siguiente código en css:


@media only screen and (min-width: 40.063em) {
#mi_menu {
width: 100%;
height: 3em;
margin: 0;
text-align: center;

}

#mi_menu .nav-bar {
height: auto;
margin: 0;
padding: 0;
display: inline-block;
}
}

Iconos vectoriales para Web

El otro día descubrí un sitio que permite descargarte iconos vectoriales para web.

Se llama fontawesome y te ofrece iconos altamente personalizables – tamaño, color, sombra y cualquier otra cosa en base a css.

En realidad lo que te descargas es una fuente en distintos formatos (svg, ttf, otf, woff, eot)  que te asegura la legibilidad en prácticamente el 100% de navegadores. La fuente  contiene más de 300 iconos representados por un identificador en su propiedad content de css:


.fa-envelope-o:before {
content: "\f003";
}

También contiene los ficheros para estilos dinámicos con sass y less.

Es muy sencillo de utilizar y personalmente los considero muy apropiados para muchas webs. El problema que veo es que este estilo de iconos se están poniendo muy de moda en muchos sitios web haciendo que parezcan todos muy similares.