La siguiente es una lista de sugerencias y mejores prácticas que debería seguir para reducir el esfuerzo de migrar una aplicación existente de Ruby on Rails de HTTP a HTTPS. Algunas de estas mejores prácticas se aplican a Ruby on Rails o al desarrollo web en general, y ya puedes seguirlas hoy mismo independientemente de tus planes de mover la aplicación bajo HTTPS.
Usar el router de la aplicación para generar dinámicamente URLs y enlaces
Una de las reglas más importantes que hay que seguir para asegurar el mantenimiento a largo plazo de una aplicación de Ruby on Rails, aparte de HTTPS, es no codificar nunca de forma dura las rutas de la aplicación en ningún lugar del código. En su lugar, siempre debes confiar en el router para generar enlaces y URLs.
No es raro ver enlaces de código duro como este en las plantillas de correo:
1Si tienes alguna pregunta, no dudes en contactar con nosotros</a>;.
html
Otro hábito muy común es codificar duramente las URL de las aplicaciones en los archivos de JavaScript o los activos estáticos.
Es muy importante confiar siempre en los ayudantes de ruta de Ruby on Rails siempre que se necesite generar una ruta. El ayudante de ruta más esencial es el url_for que es muy básico, pero extremadamente poderoso.
Para las rutas con nombre, Ruby on Rails proporciona el camino y la ayuda. Por ejemplo, si tienes una ruta llamada postes que se mapea a /posts, entonces puedes usar:
- posts_path para generar /posts
- posts_url para generar http://example.com/posts
El ayudante _url es realmente poderoso porque construye automáticamente el enlace absoluto completo usando el protocolo de solicitud y el nombre de host actuales. Por lo tanto, si usas estos helpers para generar enlaces absolutos, Ruby on Rails mostrará automáticamente los enlaces HTTPS si la petición fue hecha vía HTTPS.
Esto funciona muy bien en las plantillas que son generadas en tiempo de ejecución por el servidor. ¿Pero qué hay de un archivo estático, como un archivo JavaScript, que necesita enviar una solicitud a la aplicación? He mencionado antes que no es raro ver rutas codificadas en archivos JavaScript o CSS.
En el caso de los archivos JavaScript, puedes confiar en el atributo de datos HTML para pasar información al guión. Supongamos que tienes un script que necesita enviar una solicitud POST cuando el usuario hace clic en un botón.
1234567/// somefile.js$.post("https://example.com/loader",function(payload){$("#resultado").html(payload);});<!-- file.html---- <div ></div>js
En su lugar, genera y renderiza las URLs en la plantilla usando el ayudante _url:
12<!-- file.html --;<divdata---;</div--;
html
y cambiar el JavaScript para obtener el URL del objetivo del DOM.
1234/// somefile.js$.post($("#resultado").data("url"),function(payload){$("#resultado").html(payload);});js
12<!-- file.html --;<div>/div>
html
Usar los caminos relativos siempre que sea posible
Si utiliza rutas relativas desde la raíz, el navegador resolverá automáticamente los enlaces añadiendo el nombre de host de la petición actual y el protocolo a la ruta.
Por ejemplo, sustituir
1<linktype="image/x-icon"/;
html
con
1<linktype="image/x-icon"/;
html
Esto no es necesario si utilizas los ayudantes de ruta de Ruby on Rails que mencioné en la sección anterior.
Cargar los activos de terceros a través de HTTPS siempre que sea posible
El error más común que experimentará durante la transición de HTTP a HTTPS es la advertencia de contenido mixto. Esto sucede cuando tu sitio está usando HTTPS pero estás cargando un recurso externo (como una imagen o un archivo JavaScript) a través de HTTP.
Para evitar este problema, siempre que pueda, enlaza con la versión HTTPS de un recurso de terceros. Eso te ahorrará algunos dolores de cabeza cuando cambies tu sitio web a HTTPS. De hecho, en general no hay absolutamente ningún inconveniente en incrustar un recurso HTTPS en un sitio cargado vía HTTP, mientras que lo contrario no es cierto.
La mayoría de los proveedores de contenido están distribuyendo sus recursos tanto a través de HTTP como de HTTPS. Por ejemplo, supongamos que quieres incrustar una fuente a través de Google Font o jQuery del CDN code.jquery.com: en ambos casos, puedes enlazar inmediatamente con la versión HTTPS del recurso, no hay razón para usar el enlace HTTP.
En el pasado, también era bastante común utilizar el enlace relacionado con el protocolo para delegar en el navegador la decisión de utilizar HTTP o HTTPS en función de la solicitud.
1<linkmedia="screen"/;
html
Sin embargo, ahora que el SSL se fomenta para todo el mundo y no tiene problemas de rendimiento, esta técnica se considera un anti-patrón. Si el activo que necesitas está disponible en SSL, entonces siempre usa el enlace https://, como mencioné antes.
Tanto la opción force_ssl como la de rack-ssl están diseñadas para configurar rápidamente su aplicación para empezar a usar HTTPS con un conjunto de opciones y configuraciones de seguridad predeterminadas.
Sin embargo, ahora que su aplicación Ruby on Rails se ejecuta a través de HTTPS, es posible que desee aprovechar al máximo las ventajas de HTTPS y ajustar adecuadamente las cabeceras de seguridad devueltas por su aplicación. Echa un vistazo al curso sobre este tema, Introducción a las cabeceras de seguridad del navegador de Troy Hunt. Este curso le ayudará a comprender mejor cuáles son las cabeceras de seguridad relacionadas con HTTPS y cómo utilizarlas correctamente.