jueves, 29 de abril de 2010

Codificación del Ticket de Autenticación en la Dirección URL

Las cookies son un medio natural para la inclusión de información sobre el navegador en cada solicitud a un sitio web concreto, por lo que la configuración de autenticación por defecto forms utilizar cookies cuando el dispositivo visitando las admite. Si las cookies no son compatibles, debemos usar una alternativa para pasar el Ticket de autenticación desde el cliente al servidor. Una solución común usada en ambientes sin cookies es codificar los datos de la cookie en la URL.

La mejor manera de ver cómo esa información puede ser embebido dentro de la URL y forzar el sitio para que utilice la autenticación sin cookies. Esto se puede lograr mediante el establecimiento de la configuración de cookieless configurado a UseUri, ejemplo:

<authentication mode="Forms">
      <forms
          cookieless="UseUri"
          slidingExpiration="true"
          timeout="60"/>
    </authentication>

Una vez realizado este cambio, cuando visitemos el sitio a través del navegador como usuario anónimo, por ejemplo la dirección URL de la página Default.aspx la barra de direcciones mostrará:

http://localhost/misitio/default.aspx

Sin embargo, al iniciar la sesión, el ticket de autenticación de formularios está incrustado en la URL. Por ejemplo, después de visitar la página de entrada e iniciar de sesión como un usuario valido, la dirección en esta ocasión es:

http://localhost/misitio/(F(jaIOIDTJxIr12xYS-VVgkqKCVAuIoW30Bu0diWi6flQC-FyMaLXJfow_Vd9GZkB2Cv-rfezq0gKadKX0YPZCkA2))/default.aspx

Entonces lo que tenemos aquí es que ahora el ticket de autenticación de formularios se ha incrustado en la URL. La cadena (F(jaIOIDTJxIr12xYS-VVgkqKCVAuIoW30Bu0diWi6flQC-FyMaLXJfow_Vd9GZkB2Cv-rfezq0gKadKX0YPZCkA2) representa la información de autenticación de codificado hexadecimal del ticket. Estos son los mismos datos que normalmente se almacenan en una cookie.

Saludos, Toby

martes, 20 de abril de 2010

Programación Orientada a Objetos (POO)

¿Qué es la Programación Orientada a Objetos?

La Programación Orientada a Objetos, POO (OOP, Object Oriented Programming, en ingles), es una técnica de programación cuyo soporte fundamental es el objeto. Un objeto es una extensión de un Tipo Abstracto de Datos (TAD). Un TAD es un tipo definido por el usuario, que encapsula un conjunto de datos y las operaciones sobre estos datos.

A la hora de definir TAD’s (u objetos) se usa un concepto que nos ayuda a representar la realidad mediante modelos informáticos, la abstracción, que es un proceso mental por el que se evitan los detalles para centrarse en las cosas más genéricas de manera que se facilite su comprensión. La diferencia entre el concepto de TAD y el de objeto radica en que además del proceso de abstracción que se utiliza para su definición, existen otros dos con los que se forma el núcleo principal de la programación orientada a objetos, estos son la herencia y el polimorfismo.

Entonces tenemos que:

1.- La programación orientada a objetos, utiliza objetos, no algorítmicos, como bloques de construcción lógicos (jerarquía de objetos).


2.- Cada objeto es una instancia de una clase.


3.- Las clases se relacionan unas con otras por medio de relaciones de herencia.

Un programa puede parecer orientado a objetos, pero si cualquiera de estos elementos no existe, no es un programa orientado a objetos.


Ventajas de la orientación a objetos

Las ventajas más importantes de la programación orientada a objetos son las siguientes:

• Mantenibilidad (facilidad de mantenimiento). Los programas que se diseñan utilizando el concepto de orientación a objetos son más fáciles de leer y comprender y el control de la complejidad del programa se consigue gracias a la ocultación de la información que permite dejar visibles sólo los detalles más relevantes.

• Modificabilidad (facilidad para modificar los programas). Se pueden realizar añadidos o supresiones a programas simplemente añadiendo, suprimiendo o modificando objetos.

• Resusabilidad. Los objetos, si han sido correctamente diseñados, se pueden usar numerosas veces y en distintos proyectos.

• Fiabilidad. Los programas orientados a objetos suelen ser más fiables ya que se basan en el uso de objetos ya definidos que están ampliamente testados.


Conceptos básicos de la orientación a objeto


Como ya hemos dicho la orientación a objetos se basa en conceptos como clase, objeto, herencia y polimorfismo, pero también en otros muchos.

• Clase: Es una descripción de un conjunto de objetos similares. Por ejemplo la clase Coches. Una clase contiene los atributos y las operaciones sobre esos atributos que hacen que una clase tenga la entidad que se desea.

• Objeto: Un objeto es una cosa, generalmente extraída del vocabulario del espacio del problema o del espacio de la solución. Todo objeto tiene un nombre (se le puede identificar), un estado (generalmente hay algunos datos asociados a él) y un comportamiento (se le pueden hacer cosas a objeto y él puede hacer cosas a otros objetos). Un objeto de la clase Coches puede ser un Ford Mustang.

• Atributo: Es una característica concreta de una clase. Por ejemplo atributos de la clase Coches pueden ser el Color, el Numero de Puertas.

• Método: Es una operación concreta de una determinada clase. Por ejemplo de la clase Coches podríamos tener un método arrancar() que lo que hace es poner en marcha el coche.

• Instancia: Es una manifestación concreta de una clase (un objeto con valores concretos). También se le suele llamar ocurrencia. Por ejemplo una instancia de la clase Coches puede ser: Un Ford Mustang, de color Gris con 3 puertas.

• Herencia: Es un mecanismo mediante el cual se puede crear una nueva clase partiendo de una existente, se dice entonces que la nueva clase hereda las características de la case existentes aunque se le puede añadir más capacidades (añadiendo datos o capacidades) o modificar las que tiene.

• Polimorfismo: Hace referencia a la posibilidad de que dos métodos implementen distintas acciones, aun teniendo el mismo nombre, dependiendo del objeto que lo ejecuta o de los parámetros que recibe.

viernes, 9 de abril de 2010

Solucion error AjaxControlToolkit - La colección de controles no puede modificarse porque el control contiene bloques de...

Ajax Control Toolkit en ASP.NET Ajax Library


Detalles de la Versión :(AspNetAjaxLibraryBeta0911.zip application, 6490K, uploaded Nov 18 2009 - 147484 downloads)

Al trabajar con esta versión de AJAX en “Visual Studio 2008 con Framework 3.5 SP1” , me arrojo el siguiente error:

“La colección de controles no puede modificarse porque el control contiene bloques de código (por ej. ).”

Las causas puede ser varias pero en mi caso solo era mover el bloque de código JavaScript fuera de la etiqueta "Head" del mi MasterPage. La MasterPage era usada por una pagina que contenía controles AJAX y un control de usuario que también tenía controles AJAX.

Dejo aquí la solución por si le pasa a alguien más. Solo era cambiar esto de la MasterPage:

<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
    <title>Prueba</title>
    <asp:ContentPlaceHolder id="head" runat="server">
    </asp:ContentPlaceHolder>
    <link rel="stylesheet" href="style.css" type="text/css" media="screen" />
    <script type="text/javascript" src=<%= ResolveUrl("JScript1.js") %>>
    </script>
</head>
<body>
...
</body>
</html>
Por esto otro:
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
    <title>Prueba</title>
    <asp:ContentPlaceHolder id="head" runat="server">
    </asp:ContentPlaceHolder>
    <link rel="stylesheet" href="style.css" type="text/css" media="screen" />
</head>
<body>
    <script type="text/javascript" src=<%= ResolveUrl("JScript1.js") %>>
    </script>
...
</body>
</html>

Si tienen otra solución me avisan.

Saludos
Toby

miércoles, 7 de abril de 2010

Solucion error AjaxControlToolkit requires ASP.NET Ajax 4.0 scripts

Ajax Control Toolkit en ASP.NET Ajax Library


Detalles de la Versión :(AspNetAjaxLibraryBeta0911.zip application, 6490K, uploaded Nov 18 2009 - 147484 downloads)

Al trabajar con esta versión de AJAX en “Visual Studio 2008 con Framework 3.5 SP1” , me arrojo el siguiente error:

“Microsoft JScript runtime error: AjaxControlToolkit requires ASP.NET Ajax 4.0 scripts. Ensure the correct version of the scripts are referenced. If you are using an ASP.NET ScriptManager, switch to the AjaxScriptManager in System.Web.Ajax.dll, or use the ToolkitScriptManager in AjaxControlToolkit.dll.”

Dejo aquí la solución por si le pasa a alguien más. Solo es cambiar esto:
<asp:ScriptManager ID="ScriptManager1" runat="server"/>
<asp:ScriptManager/>
Por esto otro:
<asp:ToolkitScriptManager ID="ScriptManager1" runat="server"/>
<asp:ToolkitScriptManager/>

Si tienen otra solución me avisan.

Saludos
Toby

Entradas populares