La mayoría de los sitios web más grandes utilizan redes de distribución de contenidos (CDN's) para hostear la mayor parte de su contenido estático, especialmente imágenes, hojas de estilo, archivos para descargar y otros contenidos. La razón por la cual hacen esto es porque mientras menos contenido hostean tendrán menos carga de trabajo sus servidores, y dichos contenidos estáticos estarán en CDN’s próximas al usuario final mejorando el tiempo de descarga. El CDN más famoso es probablemente Akamai, que casi tiene su propia internet paralela. Akamai y otros proveedores de CDN’s son muy costosos, por lo que resulta complicado acceder a ellos.
Gracias a Google ahora cualquiera puede tener su propia CDN de forma gratuita alojado en los servidores de Google. Es fácil configurar y almacenar imágenes, hojas de estilo, archivos de descargas, etc. Ahora en lugar de almacenar todo ese contenido en tu propio sitio puede hacerlo en los servidores de Google ahorrando carga de trabajo de sus servidores (y consumiendo mucho menos ancho de banda de su cuenta de hosting) y las velocidades de descarga serán mucho mejores para los usuarios finales.
¿Qué es Google App Engine?
Usando Google App Engine puede ejecutar aplicaciones web en los servidores de Google. Esto significa que puede beneficiarse de la enorme granja de servidores de Google distribuida en todo el mundo, lo cual implica una muy fácil escalabilidad e integración con aplicaciones de Google. Google App Engine es una respuesta los servicios exitosos S3 (para almacenamiento) de Amazon y EC2 (para computing).
Actualmente Google App Engine se encuentra en beta, pero está abierto para que cualquier persona pueda participar, todo lo que necesitas es una cuenta de Google y un teléfono celular. Lo que se obtiene es 500 MB de almacenamiento gratuito y hasta 5 millones de páginas vistas al mes, si utiliza más de esto hay pequeños costos por pagar. El costo de estos recursos adicionales son casi los mismos que los de Amazon S3.
Cómo crear tu propio CDN
Para utilizar Google App Engine como tu propio CDN hay que instalar algunas cosas en el equipo y editar algunos archivos de configuración. Todo este trabajo lleva un tiempo, sin embargo, después de tener todo lo que necesita es muy sencillo para subir nuevos archivos a Google.
Dado que Google App Engine actualmente sólo funciona con el lenguaje de programación Python, usted necesitará para descargarlo e instalarlo. Descargue el archivo de instalación correcto para su sistema operativo desde http://www.python.org/download/ e instale la versión Phyton 2.6.2. Descargue e instale el SDK de Google App Engine de http://code.google.com/appengine/downloads.html. El SDK es necesario para escribir y enviar las solicitudes a Google. Utilice la configuración por defecto al instalar el SDK.
Regístrese en appengine.google.com, para esto necesitas una cuenta de correo de google y un celular. Una vez cumplido los requisitos solo basta con hacer clic en el botón "Crear una solicitud" y dar un nombre a su solicitud (llamado "Identificador de aplicación"). Este nombre debe ser único entre todos los usuarios de aplicaciones, en mi caso usé “4visiones". Guarde su nueva solicitud. Después de esto tiene que especificar su número de celular. Google le enviará un SMS con un código de verificación que deberá ingresar en el sito. Esto confirma que usted es el propietario de la cuenta de Google App Engine.
Descargue el archivo http://4visiones.appspot.com/files/4visiones.zip (alojado en mi CDN) y descomprimirlo en su disco duro. Si lo desea, puede cambiar el nombre del directorio descomprimido de "4visiones" al nombre de su propia aplicación. No es realmente importante pero ayuda a organizar las cosas para el futuro.
Utilice un editor de texto para editar el archivo app.yaml en el directorio 4visiones. Cambie “application: 4visiones” por “application:
Ponga todas las imágenes en la carpeta /images, las hojas de estilo en /Stylesheets, etc. También es posible crear cualquier número de subcarpetas dentro de las mismas. Una vez que preparó todo descargue http://4visiones.appspot.com/files/deploy_4visionescdn.bat y ábralo con un editor de texto. Este archivo tiene que apuntar al directorio de instalación de Phyton, al del SDK de Google y a su directorio.
Si ha instalado el SDK de Google y Phyton en C:\Archivos de programa entonces no tienes que preocuparte, sólo cambia la última parte del archivo para que apunte a tu directorio 4visiones.Haga doble clic en el archivo recién cambiado deploy_4visionescdn. bat para subir todos los archivos del directorio 4visiones a Google.
La primera vez hay que especificar su nombre de usuario de google y la contraseña.
Listo, ahora tienes tu propio CDN! Vaya a
En cualquier momento se pueden agregar nuevos archivos (imágenes, hojas de estilo, etc) o subdirectorios a la carpeta 4visiones, solo ejecute el archivo deploy_4visionescdn.bat para subirlos. Si elimina los archivos de su directorio 4visiones y luego ejecuta el archivo bat, estos se eliminarán de la aplicación Google.
También podés ver las estadísticas de tu aplicación en Google (appengine.google.com). Por ejemplo, la cantidad de ancho de banda y espacio en disco que está utilizando, etc.
Saludos!
En SQL Server 2005 cada esquema es un espacio de nombres distinto que existe de forma independientemente del usuario de base de datos que lo creó. Es decir, un esquema simplemente es un contenedor de objetos (vistas, tablas, stored procedures, etc).
Algunas características importantes de los schemas son:
Realicé un par de pruebas referidas al uso de Schemas en una aplicación multitenant.
1 - Crear el inicio de sesión
2 - Crear el usuario de la base de datos
3 - Crear el schema en la base de datos
4 - Asignar el usuario creado al schema
5 - Asignar permisos a nivel de schema
6 - Las tablas/procedimientos que se agreguen al schema van a tener esos permisos
Notas:
- Los SP y Tablas tienen que estar dentro de cada schema para facilitar la seguridad
Create Table Schema1.Tabla1 ( Texto Varchar(10) )
Insert Into Schema1.Tabla1 Values ( 'Prueba' )
Create Procedure Schema1.usp2
- Si el usuario tiene como default un schema, entonces los SP no se tienen que ejecutar con el nombre de ese schema
Exec usp1 (el Usuario tiene como default Schema1 => el motor de base de datos busca usp1 dentro de ese schema. Si no lo encuentra busca dentro del schema dbo y sino da error)
- Dentro de los SP no hace falta usar el schema de la tabla: Esto permite que el mismo script se pueda recompilar en cada schema si tener que cambiar las intrucciones
Create Procedure Schema1.usp2
As
Select * From Tabla1 --> Accede a Schema1.Tabla1
Create Procedure Schema2.usp2
As
Select * From Tabla1 --> Accede a Schema2.Tabla1
2. Dejar habilitado el seguimiento de la página
El seguimiento de página (tracing) normalmente se encuentra apagado, sin embargo también por cuestiones de depuración puede encenderse, la forma más sencilla es hacerlo en el archivo que estemos trabaando utilizando la etiqueta Trace en la declaración de página del formulario en el que estamos trabajando, sin embargo una buena práctica es hacerlo de modo sólo local (por si necesitamos que el seguimiento esté de todos modos encendido) desde el archivo Web.config y luego apagarlo al desplegar, hacerlo de esta manera encenderá el seguimiento en todos los formularios del proyecto y evitará que se nos olvide apagarlo, lo haces con la etiqueta trace de la siguiente manera:
3. Depuración habilitada
Tener esta opción habilitada, afecta al rendimiento de la aplicación, muestra errores más detallados y sólo debe encenderse mientras estamos desarrollando precisamente para el proceso de depuración, la forma correcta de desplegar es dejando en el archivo Web.config la opción de depuración apagada, otra buena práctica en el caso de las aplicaciones ASP.NET creadas con Visual Basic es dejar las opciones explicit y strict encendidas, de este modo hacemos código mejor construído (léase 100 veces: no garantiza que perfectamente construído, pero ayuda). La forma de configurar esto es de la siguiente manera:
Los hackers pueden realizar ataques de XSS (Cross Site Scripting) cuando las cookies son accesibles del lado del cliente, intentan este tipo de ataques cuando se encuentran por ejemplo con saludos del tipo Hola ChicoDotNet en las páginas en la que se inicia sesión agregando su propio código del lado del cliente. Esto puedes dificultarlo fácilmente -valga la redundancia- cuando enciendes las cookies HttpOnly, esto se hace de la siguiente forma:
Para hacer disponible una aplicación a los clientes que no aceptan cookies se tiene la opción de colocar la sesión en la URL, muchos las utilizan por defecto para no complicarse asignando a la etiqueta sessionState el atributo cookieless con el valor UseUri, sin embargo esto abre la posibilidad de suplantar a un usuario determinado visitando la dirección que contiene la sesión, esto puedes evitarlo almacenando la sesión en una cookie que expire pronto, pero queda el problema de los clientes que no aceptan cookies, para ellos necesitas enviar la sesión en la URL, ¿Cómo resolver eso?, enciende la autodetección, eso hará que los clientes que las acepten las usen y los que no las reciban en la URL, se hace con el siguiente código en Web.config:
Las cookies seguras se emiten utilizando SSL, esto hace que la transmisión se realice en forma encriptada, para configurar SSL en IIS puedes ver el artículo en MSDN que te indica como hacerlo en IIS 6.0, en el caso de IIS 7.0 es mucho más sencillo como ya había mencionado anteriormente. Para la configuración de la transmisión de las cookies por medio de SSL utiliza el siguiente código:
7. Sesiones alargables
Para alargar el tiempo de expiración de una sesión se utiliza el atributo slidingExpiration de la etiqueta forms, esto da mayor tiempo a los hackers para suplantar a un usuario determinado, la recomendación es dejarlo como se indica a continuación:
8. Uso de cookies de autenticación por defecto
El nombre por defecto de una cookie de autenticación es .ASPXAUTH, una buena práctica es nombrar estas de manera distinta, por ejemplo utilizando un GUID, de esta manera evitamos que alguien que se firme en una aplicación del servidor y pueda modificar la cookie para firmarse en otra utilizando la primera cookie obtenida. Este valor se pondría en el lugar que indico a continuación:
9. Paso de variables por URL
El uso de Request.Querystring("variable") para operaciones de negocios debe ser evitado, sobre todo si se trata de información sensible, se debe preferir el uso de variables de sesión o de ViewState, de otro modo cualqueir persona con algo de conocimientos de programación podría hacer ataques de XSS o de SQL injection.
10. Credenciales o cadenas de conexión en Web.config
Esto es lo más común de la lista, debe evitarse a toda costa el guardar usuarios y contraseñas en etiquetas credentials y cadenas de conexión o configuraciones de aplicación en Web.config sin antes cifrarlas adecuadamente. O. K., IIS evita la descarga de estos archivos de forma remota, pero ¿Qué me dicen de los del hosting? Hay que tener mucho cuidado con esto.
