ASP.NET MVC, SEO y diferentes idiomas

Un valor muy importante de nuestras webs públicas es su posicionamiento en los motores de búsqueda. Si a ello le añadimos que debemos de soportar múltiples idiomas y que queremos aparecer bien posicionados en las búsquedas en diferentes lenguajes de los buscadores, el tema se puede poner bastante divertido.

Hay que tener en cuenta que los buscadores van a realizar su indexación sin especificar una culture en su petición, por lo que las técnicas de obtener la culture del usuario a través de la petición o de una cookie o similar no van a funcionar.

Otro aspecto a tener en cuenta es que los buscadores solo indexarán un idioma por url. ¿Esto qué quiere decir? Si, por ejemplo, tenemos la url http://myshop.com y dependiendo de la culture de la petición vamos a mostrar la página en un idioma u otro, el bot del buscador solo indexará la url para un idioma, que será el que tengamos configurado por defecto, para esa url.

Si queremos tener nuestra web correctamente indexada para inglés, español y alemán debemos tener algo similar a esto:

http://myshop.com/es

http://myshop.com/de

http://myshop.com/en

Así incluso podremos facilitarle al buscador un sitemap.xml con estas url para su indexación en varios idiomas.

¿Dónde entra ASP.NET MVC en todo esto? Pues si hemos desarrollado nuestra web con esta tecnología, podemos contar con la ventaja del sistema de enrutamiento. Registrando la siguiente ruta:

routes.MapRoute("Default",
                "{culture}/{controller}/{action}/{id}",
                 new { 
                      controller = "Home", 
                      action = "Index", 
                      id = UrlParameter.Optional, 
                      culture = "en" }  
                 );
Y teniendo un controlador base similar a este:
public class BaseController : Controller
{        
   public string CurrentLanguage { get; set; }         
   protected override void OnActionExecuting(ActionExecutingContext filterContext)
   {
             if (filterContext.RouteData.Values["culture"] != null)
             {                 
                 string culture = filterContext.RouteData.Values["culture"].ToString().ToLower();
                 if (culture == "es" || culture == "en" || culture == "de")
                 {                     
                     CurrentLanguage = culture;                     
                     Thread.CurrentThread.CurrentCulture 
                                                = CultureInfo.CreateSpecificCulture(CurrentLanguage);
                     Thread.CurrentThread.CurrentUICulture 
                                                = CultureInfo.CreateSpecificCulture(CurrentLanguage);
                 }             
              }             
     base.OnActionExecuting(filterContext);         
    }     
}
Podremos redigir automáticamente a nuestras vistas con la cultura adecuada.
Para cargar una u otra vista, dependiendo de su idioma hay múltiples técnicas, hay programadores que prefieren utilizar las mismas 
vistas y cargar diferentes ficheros de recursos y hay otros que prefieren tener diferentes vistas en cada uno de los idiomas. 
Yo prefiero una mezcla de las dos soluciones:
- Me gusta tener las cadenas en un fichero de recursos porque se pueden localizar y traducir más facilmente. Además, se pueden especificar las etiquetas lang, meta description y meta keywords para una mejor indexación por parte del bot del buscador.
- Y me gusta tener diferentes vistas por idioma porque, dependiendo del idioma utilizado, las cadenas de texto pueden ocupar una u otra longitud, por lo que, por cuestiones de diseño,
esta opción puede ser interesante.

Seguridad en .NET 4

Uno de los aspectos del framework que ha cambiado de manera más radical es su modelo de seguridad. En la versión .NET 4 se ha dejado obsoleto al CAS policy.

CAS policy es una tecnología potente que permitía la aplicación de permisos de una manera muy detallada, pero demasiado engorrosa, ya que ni siquiera se pueden aplicar políticas para varias versiones del framework, etc.

Con la salida de .NET 4, Microsoft decidió cambiar la manera de hacer las cosas y trasladó la responsabilidad de la seguridad del runtime al sistema operativo, sustituyendo así las políticas a nivel de máquina y trantando de igual manera a ensamblados manejados y ensamblados nativos.

Muchos de nosotros nos habremos encontrado con la necesidad de migrar código de versiones anteriores a la nueva versión del framework y hemos tenido que hacer uso de:

<NetFx40_LegacySecurityPolicy enabled=»true» />

para habilitar la compatibilidad con CAS policy de nuestros nuevos ensamblados.

 

Para facilitar la creación de entornos sandbox, hemos pasado de la farragosa vía que CAS policy ofrecía a una manera simple y directa, con dos niveles: Partial Trust y Full Trust. Ahorrándonos la evaluación de evidencias, utilizadas ahora como meros contenedores de información.

 

El mecanismo que garantiza este comportamiento ya fue introducido en el framework .NET 2.0 y se llama Security Transparency, solo que esta primera versión era principalmente utilizada como herramienta de autidoría. En esta segunda versión incluida en .NET 4 es la herramienta que separa el código seguro de ejecutar del que no lo es.

Separa al código en tres categorías: Transparent, Safe Critical y Critical. Robando una imagen de la MSDN, sería algo así:

securitytransparencymodel

Donde las fechas verdes representan llamadas válidas y las rojas llamadas inválidas.

 

Un atributo que hemos visto en la nueva versión del framework y que puede decorar nuestros ensamblados es AllowPartiallyTrustedCallers, informando de que ese ensamblado expone cierta funcionalidad sensible en terminos de seguridad a ensamblados Partial Trust.

Para evitar que cualquier ensamblado Partial Trust pueda llamar a esa funcionalidad, se ha introducido un condicionante que, a través de una lista de hosts, hace visible esa funcionalidad solo para los nombres de esa lista.

Windows Azure AppFabric SDK V1.5

En estos días que corren, no todo va a ser Windows 8.

Se ha publicado la versión 1.5 del SDK de Windows Azure AppFabric que trae novedades principalmente en la parte de Service Bus, incluyendo mensajería brokered como topics, colas y subscripciones.

Junto a la descarga del SDK, tenéis ejemplos de las nuevas funcionalidades en Visual C# y Visual Basic.NET

Próximamente se incluirán más detalles sobre este nuevo sdk en su sección correspondiente de la MSDN.

Un saludo.

EDITO:

Hoy también se anuncia Windows Azure SDK 1.5 y hay más detalles sobre las nuevas features en el Service Bus:

Service Bus September Release

This new release introduces enhancements to the Service Bus that improve pub/sub messaging by introducing features such as Queues, Topics and Subscriptions, and Rules. It also enables new scenarios on the Windows Azure platform, such as:

  • Asynchronous Cloud Eventing – Distribute event notifications to occasionally connected clients (for example, phones, remote workers, kiosks, and so on)
  • Event-driven Service Oriented Architecture (SOA) – Building loosely coupled systems that can easily evolve over time
  • Advanced Intra-App Messaging – Load leveling and load balancing for building highly scalable and resilient applications