delete pages that were never translated from en-US (es, part 2) (#1550)

2 files changed, 0 insertions, 483 deletions

diff --git a/files/es/learn/server-side/django/django_assessment_blog/index.html b/files/es/learn/server-side/django/django_assessment_blog/index.html
deleted file mode 100644
index cb5ac7ad88..0000000000
--- a/files/es/learn/server-side/django/django_assessment_blog/index.html
+++ /dev/null
@@ -1,307 +0,0 @@
----
-title: 'Evaluación: DIY Django mini blog'
-slug: Learn/Server-side/Django/django_assessment_blog
-translation_of: Learn/Server-side/Django/django_assessment_blog
----
-<div>{{LearnSidebar}}</div>
-
-<div>{{PreviousMenu("Learn/Server-side/Django/web_application_security", "Learn/Server-side/Django")}}</div>
-
-<p class="summary">En esta evaluación usarás el conocimiento de Django que has adquirido en el módulo <a href="/es/docs/Learn/Server-side/Django" style="font-size: 1.25rem;">Framework Web Django (Python)</a> para crear un blog muy básico<span style="font-size: 1.25rem;">.</span></p>
-
-<table class="learn-box standard-table">
- <tbody>
-  <tr>
-   <th scope="row">Requisitos Previos:</th>
-   <td>Before attempting this assessment you should have already worked through all the articles in this module.</td>
-  </tr>
-  <tr>
-   <th scope="row">Objetivo:</th>
-   <td>Comprender los fundamentos de Django , incluidos las configuraciones de URL , modelos, vistas, formularios y  templates.</td>
-  </tr>
- </tbody>
-</table>
-
-<h2 id="Resumen_del_proyecto">Resumen del proyecto</h2>
-
-<p>Las paginas que necesitan ser mostradas, sus URLs, y otros requisitos son listados debajo: </p>
-
-<table class="standard-table">
- <thead>
-  <tr>
-   <th scope="col">Pagina</th>
-   <th scope="col">URL</th>
-   <th scope="col">Requisitos</th>
-  </tr>
- </thead>
- <tbody>
-  <tr>
-   <td>Home page</td>
-   <td><code>/</code> and <code>/blog/</code></td>
-   <td>Una pagina inicial que describa el sitio</td>
-  </tr>
-  <tr>
-   <td>Lista de todos las publicaciones del blog</td>
-   <td><code>/blog/blogs/</code></td>
-   <td>
-    <p>Lista de todos las publicaciones del blog:</p>
-
-    <ul>
-     <li>Accessible to all users from a sidebar link.</li>
-     <li>List sorted by post date (newest to oldest).</li>
-     <li>List paginated in groups of 5 articles.</li>
-     <li>List items display the blog title, post date, and author.</li>
-     <li>Blog post names are linked to blog detail pages.</li>
-     <li>Blogger (author names) are linked to blog author detail pages.</li>
-    </ul>
-   </td>
-  </tr>
-  <tr>
-   <td>Blog autor (blogger) pagina de detalles</td>
-   <td><code>/blog/blogger/<em>&lt;author-id&gt;</em></code></td>
-   <td>
-    <p>Information for a specified author (by id) and list of their blog posts:</p>
-
-    <ul>
-     <li>Accessible to all users from author links in blog posts etc.</li>
-     <li>Contains some biographical information about the blogger/author.</li>
-     <li>List sorted by post date (newest to oldest).</li>
-     <li>Not paginated.</li>
-     <li>List items display just the blog post name and post date.</li>
-     <li>Blog post names are linked to blog detail pages.</li>
-    </ul>
-   </td>
-  </tr>
-  <tr>
-   <td>Blog post detail page</td>
-   <td><code>/blog/<em>&lt;blog-id&gt;</em></code></td>
-   <td>
-    <p>Blog post details.</p>
-
-    <ul>
-     <li>Accessible to all users from blog post lists.</li>
-     <li>Page contains the blog post: name, author, post date, and content.</li>
-     <li>Comments for the blog post should be displayed at bottom.</li>
-     <li>Comments should be sorted in order: oldest to most recent.</li>
-     <li>Contains link to add comments at end for logged in users (see Comment form page)</li>
-     <li>Blog posts and comments need only display plain text. There is no need to support any sort of HTML markup (e.g. links, images, bold/italic, etc).</li>
-    </ul>
-   </td>
-  </tr>
-  <tr>
-   <td>List of all bloggers</td>
-   <td><code>/blog/bloggers/</code></td>
-   <td>
-    <p>List of bloggers on system:</p>
-
-    <ul>
-     <li>Accessible to all users from site sidebar</li>
-     <li>Blogger names are linked to Blog author detail pages.</li>
-    </ul>
-   </td>
-  </tr>
-  <tr>
-   <td>Comment form page</td>
-   <td><code>/blog/<em>&lt;blog-id&gt;</em>/create</code></td>
-   <td>
-    <p>Create comment for blog post:</p>
-
-    <ul>
-     <li>Accessible to logged-in users (only) from link at bottom of blog post detail pages.</li>
-     <li>Displays form with description for entering comments (post date and blog is not editable).</li>
-     <li>After a comment has been posted, the page will redirect back to the associated blog post page.</li>
-     <li>Users cannot edit or delete their posts.</li>
-     <li>Logged out users will be directed to the login page to log in, before they can add comments. After logging in, they will be redirected back to the blog page they wanted to comment on.</li>
-     <li>Comment pages should include the name/link to the blogpost being commented on.</li>
-    </ul>
-   </td>
-  </tr>
-  <tr>
-   <td>User authentication pages</td>
-   <td><code>/accounts/<em>&lt;standard urls&gt;</em></code></td>
-   <td>
-    <p>Standard Django authentication pages for logging in, out and setting the password:</p>
-
-    <ul>
-     <li>Login/out should be accessible via sidebar links.</li>
-    </ul>
-   </td>
-  </tr>
-  <tr>
-   <td>Admin site</td>
-   <td><code>/admin/<em>&lt;standard urls&gt;</em></code></td>
-   <td>
-    <p>Admin site should be enabled to allow create/edit/delete of blog posts, blog authors and blog comments (this is the mechanism for bloggers to create new blog posts):</p>
-
-    <ul>
-     <li>Admin site blog posts records should display the list of associated comments inline (below each blog post).</li>
-     <li>Comment names in the Admin site are created by truncating the comment description to 75 characters.</li>
-     <li>Other types of records can use basic registration.</li>
-    </ul>
-   </td>
-  </tr>
- </tbody>
-</table>
-
-<p>In addition you should write some basic tests to verify:</p>
-
-<ul>
- <li>All model fields have the correct label and length.</li>
- <li>All models have the expected object name (e.g.<code> __str__()</code> returns the expected value).</li>
- <li>Models have the expected URL for individual Blog and Comment records (e.g. <code>get_absolute_url()</code> returns the expected URL).</li>
- <li>The BlogListView (all-blog page) is accessible at the expected location (e.g. /blog/blogs)</li>
- <li>The BlogListView (all-blog page) is accessible at the expected named url (e.g. 'blogs')</li>
- <li>The BlogListView (all-blog page) uses the expected template (e.g. the default)</li>
- <li>The BlogListView paginates records by 5 (at least on the first page)</li>
-</ul>
-
-<div class="note">
-<p><strong>Note</strong>: There are of course many other tests you can run. Use your discretion, but we'll expect you to do at least the tests above.</p>
-</div>
-
-<p>The following section shows <a href="#Screenshots">screenshots</a> of a site that implements the requirements above.</p>
-
-<h2 id="Screenshots">Screenshots</h2>
-
-<p>The following screenshot provide an example of what the finished program should output.</p>
-
-<h3 id="List_of_all_blog_posts">List of all blog posts</h3>
-
-<p>This displays the list of all blog posts (accessible from the "All blogs" link in the sidebar). Things to note:</p>
-
-<ul>
- <li>The sidebar also lists the logged in user.</li>
- <li>Individual blog posts and bloggers are accessible as links in the page.</li>
- <li>Pagination is enabled (in groups of 5)</li>
- <li>Ordering is newest to oldest.</li>
-</ul>
-
-<p><img alt="List of all blogs" src="https://mdn.mozillademos.org/files/14319/diyblog_allblogs.png" style="border-style: solid; border-width: 1px; display: block; height: 363px; margin: 0px auto; width: 986px;"></p>
-
-<h3 id="List_of_all_bloggers">List of all bloggers</h3>
-
-<p>This provides links to all bloggers, as linked from the "All bloggers" link in the sidebar. In this case we can see from the sidebar that no user is logged in.</p>
-
-<p><img alt="List of all bloggers" src="https://mdn.mozillademos.org/files/14321/diyblog_blog_allbloggers.png" style="border-style: solid; border-width: 1px; display: block; height: 256px; margin: 0px auto; width: 493px;"></p>
-
-<h3 id="Blog_detail_page">Blog detail page</h3>
-
-<p>This shows the detail page for a particular blog.</p>
-
-<p><img alt="Blog detail with add comment link" src="https://mdn.mozillademos.org/files/14323/diyblog_blog_detail_add_comment.png" style="border-style: solid; border-width: 1px; display: block; height: 640px; margin: 0px auto; width: 986px;"></p>
-
-<p>Note that the comments have a date <em>and</em> time, and are ordered from oldest to newest (opposite of blog ordering). At the end we have a link for accessing the form to add a new comment. If a user is not logged in we'd instead see a suggestion to log in.</p>
-
-<p><img alt="Comment link when not logged in" src="https://mdn.mozillademos.org/files/14325/diyblog_blog_detail_not_logged_in.png" style="border-style: solid; border-width: 1px; display: block; height: 129px; margin: 0px auto; width: 646px;"></p>
-
-<h3 id="Add_comment_form">Add comment form</h3>
-
-<p>This is the form to add comments. Note that we're logged in. When this succeeds we should be taken back to the associated blog post page.</p>
-
-<p><img alt="Add comment form" src="https://mdn.mozillademos.org/files/14329/diyblog_comment_form.png" style="border-style: solid; border-width: 1px; display: block; height: 385px; margin: 0px auto; width: 778px;"></p>
-
-<h3 id="Author_bio">Author bio</h3>
-
-<p>This displays bio information for a blogger along with their blog posts list.</p>
-
-<p><img alt="Blogger detail page" src="https://mdn.mozillademos.org/files/14327/diyblog_blogger_detail.png" style="border-style: solid; border-width: 1px; display: block; height: 379px; margin: 0px auto; width: 982px;"></p>
-
-<h2 id="Steps_to_complete">Steps to complete</h2>
-
-<p>The following sections describe what you need to do.</p>
-
-<ol>
- <li>Create a skeleton project and web application for the site (as described in <a href="/en-US/docs/Learn/Server-side/Django/skeleton_website">Django Tutorial Part 2: Creating a skeleton website</a>). You might use 'diyblog' for the project name and 'blog' for the application name.</li>
- <li>Create models for the Blog posts, Comments, and any other objects needed. When thinking about your design, remember:
-  <ul>
-   <li>Each comment will have only one blog, but a blog may have many comments.</li>
-   <li>Blog posts and comments must be sorted by post date.</li>
-   <li>Not every user will necessarily be a blog author though any user may be a commenter.</li>
-   <li>Blog authors must also include bio information.</li>
-  </ul>
- </li>
- <li>Run migrations for your new models and create a superuser.</li>
- <li>Use the admin site to create some example blog posts and blog comments.</li>
- <li>Create views, templates, and URL configurations for blog post and blogger list pages.</li>
- <li>Create views, templates, and URL configurations for blog post and blogger detail pages.</li>
- <li>Create a page with a form for adding new comments (remember to make this only available to logged in users!)</li>
-</ol>
-
-<h2 id="Hints_and_tips">Hints and tips</h2>
-
-<p>This project is very similar to the <a href="/en-US/docs/Learn/Server-side/Django/Tutorial_local_library_website">LocalLibrary</a> tutorial. You will be able to set up the skeleton, user login/logout behaviour, support for static files, views, URLs, forms, base templates and admin site configuration using almost all the same approaches.</p>
-
-<p>Some general hints:</p>
-
-<ol>
- <li>The index page can be implemented as a basic function view and template (just like for the locallibrary).</li>
- <li>The list view for blog posts and bloggers, and the detail view for blog posts can be created using the <a href="/en-US/docs/Learn/Server-side/Django/Generic_views">generic list and detail views</a>.</li>
- <li>The list of blog posts for a particular author can be created by using a generic list Blog list view and filtering for blog object that match the specified author.
-  <ul>
-   <li>You will have to implement <code>get_queryset(self)</code> to do the filtering (much like in our library class <code>LoanedBooksAllListView</code>) and get the author information from the URL.</li>
-   <li>You will also need to pass the name of the author to the page in the context. To do this in a class-based view you need to implement <code>get_context_data()</code> (discussed below).</li>
-  </ul>
- </li>
- <li>The <em>add comment</em> form can be created using a function-based view (and associated model and form) or using a generic <code>CreateView</code>. If you use a <code>CreateView</code> (recommended) then:
-  <ul>
-   <li>You will also need to pass the name of the blog post to the comment page in the context (implement <code>get_context_data()</code> as discussed below).</li>
-   <li>The form should only display the comment "description" for user entry (date and associated blog post should not be editable). Since they won't be in the form itself, your code will need to set the comment's author in the<code> form_valid()</code> function so it can be saved into the model (<a href="https://docs.djangoproject.com/en/1.10/topics/class-based-views/generic-editing/#models-and-request-user">as described here</a> — Django docs). In that same function we set the associated blog. A possible implementation is shown below (<code>pk</code> is a blog id passed in from the URL/URL configuration).
-    <pre class="brush: python">    def form_valid(self, form):
-        """
-        Add author and associated blog to form data before setting it as valid (so it is saved to model)
-        """
-        #Add logged-in user as author of comment
-        form.instance.author = self.request.user
-        #Associate comment with blog based on passed id
-        form.instance.blog=get_object_or_404(Blog, pk = self.kwargs['pk'])
-        # Call super-class form validation behaviour
-        return super(BlogCommentCreate, self).form_valid(form)
-</pre>
-   </li>
-   <li>You will need to provide a success URL to redirect to after the form validates; this should be the original blog. To do this you will need to override <code>get_success_url()</code> and "reverse" the URL for the original blog. You can get the required blog ID using the <code>self.kwargs</code> attribute, as shown in the <code>form_valid()</code> method above.</li>
-  </ul>
- </li>
-</ol>
-
-<p>We briefly talked about passing a context to the template in a class-based view in the <a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Generic_views#Overriding_methods_in_class-based_views">Django Tutorial Part 6: Generic list and detail views</a> topic. To do this you need to override <code>get_queryset()</code> (first getting the existing context, updating it with whatever additional variables you want to pass to the template, and then returning the updated context. For example, the code fragment below shows how you can add a blogger object to the context based on their <code>BlogAuthor</code> id.</p>
-
-<pre class="brush: python">class SomeView(generic.ListView):
-    ...
-
-    def get_context_data(self, **kwargs):
-        # Call the base implementation first to get a context
-        context = super(SomeView, self).get_context_data(**kwargs)
-        # Get the blogger object from the "pk" URL parameter and add it to the context
-        context['blogger'] = get_object_or_404(BlogAuthor, pk = self.kwargs['pk'])
-        return context
-</pre>
-
-<h2 id="Assessment">Assessment</h2>
-
-<p>The assessment for this task is <a href="https://github.com/mdn/django-diy-blog/blob/master/MarkingGuide.md">available on Github here</a>. This assessment is primarily based on how well your application meets the requirements we listed above, though there are some parts of the assessment that check your code uses appropriate models, and that you have written at least some test code. When you're done, you can check out our <a href="https://github.com/mdn/django-diy-blog">the finished example</a> which reflects a "full marks" project.</p>
-
-<p>Once you've completed this module you've also finished all the MDN content for learning basic Django server-side website programming! We hope you enjoyed this module and feel you have a good grasp of the basics!</p>
-
-<p>{{PreviousMenu("Learn/Server-side/Django/web_application_security", "Learn/Server-side/Django")}}</p>
-
-<p> </p>
-
-<h2 id="En_este_modulo">En este modulo</h2>
-
-<ul>
- <li><a href="/es/docs/Learn/Server-side/Django/Introducción">Introducción a Django</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/development_environment">Configurando un entorno de desarrollo Django</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Tutorial_local_library_website">Tutorial de Django: El sito web de la Biblioteca Local</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/skeleton_website">Tutorial de Django Parte 2: Creando el esqueleto de un sitio web</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Models">Tutorial de Django Parte 3: Usando modelos</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Admin_site">Tutorial de Django Parte 4: Sitio de administración de Django</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Home_page">Tutorial de Django Parte 5: Creando nuestra página de inicio</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Generic_views">Tutorial de Django Parte 6: Listas genéricas y vistas de detalle</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Sessions">Tutorial de Django Parte 7: Framework de sesiones</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Authentication">Tutorial de Django Parte 8: Autenticación de usuarios y permisos</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Forms">Tutorial de Django Parte 9: Trabajando con formularios</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Testing">Tutorial de Django Parte 10: Probando una aplicación web de Django</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Deployment">Tutorial de Django Parte 11: Poniendo Django en producción</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/web_application_security">Seguridad en aplicaciones web Django</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/django_assessment_blog">DIY Django mini blog</a></li>
-</ul>
diff --git a/files/es/learn/server-side/django/web_application_security/index.html b/files/es/learn/server-side/django/web_application_security/index.html
deleted file mode 100644
index e00a1771bb..0000000000
--- a/files/es/learn/server-side/django/web_application_security/index.html
+++ /dev/null
@@ -1,176 +0,0 @@
----
-title: Seguridad de las aplicaciones web Django
-slug: Learn/Server-side/Django/web_application_security
-translation_of: Learn/Server-side/Django/web_application_security
----
-<div>{{LearnSidebar}}</div>
-
-<div>{{PreviousMenuNext("Learn/Server-side/Django/Deployment", "Learn/Server-side/Django/django_assessment_blog", "Learn/Server-side/Django")}}</div>
-
-<p class="summary">Proteger los datos de los usuarios es una parte esencial de cualquier diseño de un sitio web. Previamente ya explicamos algunas de las amenazas de seguridad más comunes en el artículo <a href="https://developer.mozilla.org/en-US/docs/Web/Security">Seguridad Web</a> — este artículo proporciona una demostración práctica de cómo las protecciones integradas de Django gestionan estas amenazas.</p>
-
-<table class="learn-box standard-table">
- <tbody>
-  <tr>
-   <th scope="row">Prerrequisitos:</th>
-   <td>Lee la documentación de la Programación del Lado del servidor "<a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/First_steps/Website_security">Seguridad de la aplicación web de Django</a>". Completa todos los temas del Tutorial de Django (incluyendo este) o por lo menos el <a href="/en-US/docs/Learn/Server-side/Django/Forms">Tutorial de Django Parte 9: Trabajar con formularios web</a>.</td>
-  </tr>
-  <tr>
-   <th scope="row">Objetivo:</th>
-   <td>Comprender las cosas principales que debes hacer (y las que no debes) para proteger su aplicación web de Django.</td>
-  </tr>
- </tbody>
-</table>
-
-<h2 id="Overview">Overview</h2>
-
-<p>The <a href="https://developer.mozilla.org/en-US/docs/Web/Security">Website security</a> topic provides an overview of what website security means for server-side design, and some of the more common threats that you may need to protect against. One of the key messages in that article is that almost all attacks are successful when the web application trusts data from the browser.</p>
-
-<div class="warning">
-<p><strong>Important:</strong> The single most important lesson you can learn about website security is to <strong>never trust data from the browser</strong>. This includes <code>GET</code> request data in URL parameters, <code>POST</code> data, HTTP headers and cookies, user-uploaded files, etc. Always check and sanitize all incoming data. Always assume the worst.</p>
-</div>
-
-<p>The good news for Django users is that many of the more common threats are handled by the framework! The <a href="https://docs.djangoproject.com/en/1.10/topics/security/">Security in Django</a> (Django docs) article explains Django's security features and how to secure a Django-powered website.</p>
-
-<h2 id="Common_threatsprotections">Common threats/protections</h2>
-
-<p>Rather than duplicate the Django documentation here, in this article we'll demonstrate just a few of the security features in the context of our Django <a href="/en-US/docs/Learn/Server-side/Django/Tutorial_local_library_website">LocalLibrary</a> tutorial.</p>
-
-<h3 id="Cross_site_scripting_(XSS)">Cross site scripting (XSS)</h3>
-
-<p>XSS is a term used to describe a class of attacks that allow an attacker to inject client-side scripts <em>through</em> the website into the browsers of other users. This is usually achieved by storing malicious scripts in the database where they can be retrieved and displayed to other users, or by getting users to click a link that will cause the attacker’s JavaScript to be executed by the user’s browser.</p>
-
-<p>Django's template system protects you against the majority of XSS attacks by <a href="https://docs.djangoproject.com/en/1.10/ref/templates/language/#automatic-html-escaping">escaping specific characters</a> that are "dangerous" in HTML. We can demonstrate this by attempting to inject some JavaScript into our LocalLibrary website using the Create-author form we set up in <a href="/en-US/docs/Learn/Server-side/Django/Forms">Django Tutorial Part 9: Working with forms</a>.</p>
-
-<ol>
- <li>Start the website using the development server (<code>python3 manage.py runserver</code>).</li>
- <li>Open the site in your local browser and login to your superuser account.</li>
- <li>Navigate to the author-creation page (which should be at URL: <code><a href="http://127.0.0.1:8000/catalog/author/create/">http://127.0.0.1:8000/catalog/author/create/</a></code>).</li>
- <li>Enter names and date details for a new user, and then append the following text to the Last Name field:<br>
-  <code>&lt;script&gt;alert('Test alert');&lt;/script&gt;</code>.<br>
-  <img alt="Author Form XSS test" src="https://mdn.mozillademos.org/files/14305/author_create_form_alert_xss.png" style="border-style: solid; border-width: 1px; height: 245px; width: 594px;">
-  <div class="note">
-  <p><strong>Note:</strong> This is a harmless script that, if executed, will display an alert box in your browser. If the alert is displayed when you submit the record then the site is vulnerable to XSS threats.</p>
-  </div>
- </li>
- <li>Press <strong>Submit</strong> to save the record.</li>
- <li>When you save the author it will be displayed as shown below. Because of the XSS protections the <code>alert()</code> should not be run. Instead the script is displayed as plain text.<img alt="Author detail view XSS test" src="https://mdn.mozillademos.org/files/14307/author_detail_alert_xss.png" style="border-style: solid; border-width: 1px; height: 248px; width: 986px;"></li>
-</ol>
-
-<p>If you view the page HTML source code, you can see that the dangerous characters for the script tags have been turned into their harmless escape code equivalents (e.g. <code>&gt;</code> is now <code>&amp;gt;</code>)</p>
-
-<pre class="brush: html">&lt;h1&gt;Author: Boon&amp;lt;script&amp;gt;alert(&amp;#39;Test alert&amp;#39;);&amp;lt;/script&amp;gt;, David (Boonie) &lt;/h1&gt;
-</pre>
-
-<p>Using Django templates protects you against the majority of XSS attacks. However it is possible to turn off this protection, and the protection isn't automatically applied to all tags that wouldn't normally be populated by user input (for example, the <code>help_text</code> in a form field is usually not user-supplied, so Django doesn't escape those values).</p>
-
-<p>It is also possible for XSS attacks to originate from other untrusted source of data, such as cookies, Web services or uploaded files (whenever the data is not sufficiently sanitized before including in a page). If you're displaying data from these sources, then you may need to add your own sanitisation code.</p>
-
-<h3 id="Cross_site_request_forgery_(CSRF)_protection">Cross site request forgery (CSRF) protection</h3>
-
-<p>CSRF attacks allow a malicious user to execute actions using the credentials of another user without that user’s knowledge or consent. For example consider the case where we have a hacker who wants to create additional authors for our LocalLibrary.</p>
-
-<div class="note">
-<p><strong>Note:</strong> Obviously our hacker isn't in this for the money! A more ambitious hacker could use the same approach on other sites to perform much more harmful tasks (e.g. transfer money to their own accounts, etc.)</p>
-</div>
-
-<p>In order to do this, they might create an HTML file like the one below, which contains an author-creation form (like the one we used in the previous section) that is submitted as soon as the file is loaded. They would then send the file to all the Librarians and suggest that they open the file (it contains some harmless information, honest!). If the file is opened by any logged in librarian, then the form would be submitted with their credentials and a new author would be created.</p>
-
-<pre class="brush: html">&lt;html&gt;
-&lt;body onload='document.EvilForm.submit()'&gt;
-
-&lt;form action="http://127.0.0.1:8000/catalog/author/create/" method="post" name='EvilForm'&gt;
-  &lt;table&gt;
-    &lt;tr&gt;&lt;th&gt;&lt;label for="id_first_name"&gt;First name:&lt;/label&gt;&lt;/th&gt;&lt;td&gt;&lt;input id="id_first_name" maxlength="100" name="first_name" type="text" value="Mad" required /&gt;&lt;/td&gt;&lt;/tr&gt;
-    &lt;tr&gt;&lt;th&gt;&lt;label for="id_last_name"&gt;Last name:&lt;/label&gt;&lt;/th&gt;&lt;td&gt;&lt;input id="id_last_name" maxlength="100" name="last_name" type="text" value="Man" required /&gt;&lt;/td&gt;&lt;/tr&gt;
-    &lt;tr&gt;&lt;th&gt;&lt;label for="id_date_of_birth"&gt;Date of birth:&lt;/label&gt;&lt;/th&gt;&lt;td&gt;&lt;input id="id_date_of_birth" name="date_of_birth" type="text" /&gt;&lt;/td&gt;&lt;/tr&gt;
-    &lt;tr&gt;&lt;th&gt;&lt;label for="id_date_of_death"&gt;Died:&lt;/label&gt;&lt;/th&gt;&lt;td&gt;&lt;input id="id_date_of_death" name="date_of_death" type="text" value="12/10/2016" /&gt;&lt;/td&gt;&lt;/tr&gt;
-  &lt;/table&gt;
-  &lt;input type="submit" value="Submit" /&gt;
-&lt;/form&gt;
-
-&lt;/body&gt;
-&lt;/html&gt;
-</pre>
-
-<p>Run the development web server, and log in with your superuser account. Copy the text above into a file and then open it in the browser. You should get a CSRF error, because Django has protection against this kind of thing!</p>
-
-<p>The way the protection is enabled is that you include the <code>{% csrf_token %}</code> template tag in your form definition. This token is then rendered in your HTML as shown below, with a value that is specific to the user on the current browser.</p>
-
-<pre class="brush: html">&lt;input type='hidden' name='csrfmiddlewaretoken' value='0QRWHnYVg776y2l66mcvZqp8alrv4lb8S8lZ4ZJUWGZFA5VHrVfL2mpH29YZ39PW' /&gt;
-</pre>
-
-<p>Django generates a user/browser specific key and will reject forms that do not contain the field, or that contain an incorrect field value for the user/browser.</p>
-
-<p>To use this type of attack the hacker now has to discover and include the CSRF key for the specific target user. They also can't use the "scattergun" approach of sending a malicious file to all librarians and hoping that one of them will open it, since the CSRF key is browser specific.</p>
-
-<p>Django's CSRF protection is turned on by default. You should always use the <code>{% csrf_token %}</code> template tag in your forms and use <code>POST</code> for requests that might change or add data to the database.</p>
-
-<h3 id="Other_protections">Other protections</h3>
-
-<p>Django also provides other forms of protection (most of which would be hard or not particularly useful to demonstrate):</p>
-
-<dl>
- <dt>SQL injection protection</dt>
- <dd>SQL injection vulnerabilities enable malicious users to execute arbitrary SQL code on a database, allowing data to be accessed, modified, or deleted irrespective of the user's permissions. In almost every case you'll be accessing the database using Django’s querysets/models, so the resulting SQL will be properly escaped by the underlying database driver. If you do need to write raw queries or custom SQL then you'll need to explicitly think about preventing SQL injection.</dd>
- <dt>Clickjacking protection</dt>
- <dd>In this attack a malicious user hijacks clicks meant for a visible top level site and routes them to a hidden page beneath. This technique might be used, for example, to display a legitimate bank site but capture the login credentials in an invisible <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe" title="The HTML Inline Frame Element (&lt;iframe>) represents a nested browsing context, effectively embedding another HTML page into the current page. In HTML 4.01, a document may contain a head and a body or a head and a frameset, but not both a body and a frameset. However, an &lt;iframe> can be used within a normal document body. Each browsing context has its own session history and active document. The browsing context that contains the embedded content is called the parent browsing context. The top-level browsing context (which has no parent) is typically the browser window."><code>&lt;iframe&gt;</code></a> controlled by the attacker. Django contains <a href="https://docs.djangoproject.com/en/1.10/ref/clickjacking/#clickjacking-prevention">clickjacking protection</a> in the form of the <a href="https://docs.djangoproject.com/en/1.10/ref/middleware/#django.middleware.clickjacking.XFrameOptionsMiddleware" title="django.middleware.clickjacking.XFrameOptionsMiddleware"><code>X-Frame-Options middleware</code></a> which, in a supporting browser, can prevent a site from being rendered inside a frame.</dd>
- <dt>Enforcing SSL/HTTPS</dt>
- <dd>SSL/HTTPS can be enabled on the web server in order to encrypt all traffic between the site and browser, including authentication credentials that would otherwise be sent in plain text (enabling HTTPS is highly recommended). If HTTPS is enabled then Django provides a number of other protections you can use:</dd>
-</dl>
-
-<ul>
- <li><a href="https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-SECURE_PROXY_SSL_HEADER"><code>SECURE_PROXY_SSL_HEADER</code></a> can be used to check whether content is secure, even if it is incoming from a non-HTTP proxy.</li>
- <li><a href="https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-SECURE_SSL_REDIRECT"><code>SECURE_SSL_REDIRECT</code></a> is used to redirect all HTTP requests to HTTPS.</li>
- <li>Use <a href="https://docs.djangoproject.com/en/1.10/ref/middleware/#http-strict-transport-security">HTTP Strict Transport Security</a> (HSTS). This is an HTTP header that informs a browser that all future connections to a particular site should always use HTTPS. Combined with redirecting HTTP requests to HTTPS, this setting ensures that HTTPS is always used after a successful connection has occurred. HSTS may either be configured with <a href="https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-SECURE_HSTS_SECONDS"><code>SECURE_HSTS_SECONDS</code></a> and <a href="https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-SECURE_HSTS_INCLUDE_SUBDOMAINS"><code>SECURE_HSTS_INCLUDE_SUBDOMAINS</code></a> or on the Web server.</li>
- <li>Use ‘secure’ cookies by setting <a href="https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-SESSION_COOKIE_SECURE"><code>SESSION_COOKIE_SECURE</code></a> and <a href="https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-CSRF_COOKIE_SECURE"><code>CSRF_COOKIE_SECURE</code></a> to <code>True</code>. This will ensure that cookies are only ever sent over HTTPS.</li>
-</ul>
-
-<dl>
- <dt>Host header validation</dt>
- <dd>Use <a href="https://docs.djangoproject.com/en/1.10/ref/settings/#std:setting-ALLOWED_HOSTS"><code>ALLOWED_HOSTS</code></a> to only accept requests from trusted hosts.</dd>
-</dl>
-
-<p>There are many other protections, and caveats to the usage of the above mechanisms. While we hope that this has given you an overview of what Django offers, you should still read the Django security documentation.</p>
-
-<ul>
-</ul>
-
-<h2 id="Summary">Summary</h2>
-
-<p>Django has effective protections against a number of common threats, including XSS and CSRF attacks. In this article we've demonstrated how those particular threats are handled by Django in our <em>LocalLibrary</em> website. We've also provided a brief overview of some of the other protections.</p>
-
-<p>This has been a very brief foray into web security. We strongly recommend that you read <a href="https://docs.djangoproject.com/en/1.10/topics/security/">Security in Django</a> to gain a deeper understanding.</p>
-
-<p>The next and final step in this module about Django is to complete the <a href="/en-US/docs/Learn/Server-side/Django/django_assessment_blog">assessment task</a>.</p>
-
-<h2 id="See_also">See also</h2>
-
-<ul>
- <li><a href="https://docs.djangoproject.com/en/1.10/topics/security/">Security in Django</a> (Django docs)</li>
- <li><a href="https://developer.mozilla.org/en-US/docs/Web/Security">Server side website security</a> (MDN)</li>
- <li><a href="https://developer.mozilla.org/en-US/docs/Web/Security">Web security</a> (MDN)</li>
- <li><a href="/en-US/docs/Web/Security/Securing_your_site">Securing your site</a> (MDN)</li>
-</ul>
-
-<p>{{PreviousMenuNext("Learn/Server-side/Django/Deployment", "Learn/Server-side/Django/django_assessment_blog", "Learn/Server-side/Django")}}</p>
-
-<h2 id="En_este_módulo">En este módulo</h2>
-
-<ul>
- <li><a href="/es/docs/Learn/Server-side/Django/Introducción">Introducción a Django</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/development_environment">Configurando un entorno de desarrollo Django</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Tutorial_local_library_website">Tutorial de Django: El sito web de la Biblioteca Local</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/skeleton_website">Tutorial de Django Parte 2: Creando el esqueleto de un sitio web</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Models">Tutorial de Django Parte 3: Usando modelos</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Admin_site">Tutorial de Django Parte 4: Sitio de administración de Django</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Home_page">Tutorial de Django Parte 5: Creando nuestra página de inicio</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Generic_views">Tutorial de Django Parte 6: Listas genéricas y vistas de detalle</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Sessions">Tutorial de Django Parte 7: Framework de sesiones</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Authentication">Tutorial de Django Parte 8: Autenticación de usuarios y permisos</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Forms">Tutorial de Django Parte 9: Trabajando con formularios</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Testing">Tutorial de Django Parte 10: Probando una aplicación web de Django</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/Deployment">Tutorial de Django Parte 11: Poniendo Django en producción</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/web_application_security">Seguridad en aplicaciones web Django</a></li>
- <li><a href="/es/docs/Learn/Server-side/Django/django_assessment_blog">DIY Django mini blog</a></li>
-</ul>