Django'da özel middleware

This repository contains a Turkish example application that explains how middleware works in Django and how to write your own. I prepared it in May 2016 with Django 1.9. Next to the code, the repository also includes a Turkish PDF guide that walks through the topic step by step, along with its English translation.

Purpose

When an address is opened in Django, urls.py finds the matching function, the function runs and a response goes back to the browser. But if there is something that has to happen on every page, such as checking the visitor's IP address, do you have to write it into every function one by one? No; this is exactly what middleware is for. Middleware is the layer every request passes through before reaching a view, and every response passes through before it goes to the browser. Because this happens quietly inside Django, beginners often cannot see what goes on in the background. I prepared this example to show concretely, by printing to the screen, the order in which the layers run.

How it works

The sample layer is the IPKontrolMiddleware class in uyeler/ozel_islemler.py. I deliberately chose a file name other than middleware.py; I wanted readers to see that this is not a fixed rule and that Django finds the layer through the path given in the settings. The class has two methods. process_request runs when a request arrives and compares the visitor's IP address with a list of allowed addresses. If the address is not on the list, a PermissionDenied error is raised and a 403 Forbidden response is returned without the view ever running. If it is on the list, the method returns None and the request continues on its way. process_response steps in after the view has run, just before the response is sent to the browser.

The layer is added at the end of the MIDDLEWARE_CLASSES list in settings.py. In the guide I explain that the order of this list matters, because the information a layer relies on must already have been prepared by the layers before it.

How the guide progresses

At every step the guide shows the lines the development server prints to the screen. First, the home page is opened while the IP address is not on the list, and you can see the request being rejected before it reaches the view. Then the address is added to the list, and this time you can follow the order: the layer, urls.py, the view and the layer again. Finally, sign-in and sign-out pages are added. From the layer's output you can follow how request.user is AnonymousUser before signing in and becomes the user's email address afterwards.

Other parts of the sample project

• The sign-in, sign-out and members-only home page views are defined in urls.py.
• The member model in the uyeler app automatically creates a linked Django user when a new member is saved. The member's permissions to send email and post comments, a record limit and a membership end date are also stored in this model.
• The news model in the kayit app is used to calculate a member's remaining record limit.
• Because the project uses SQLite, it can be run right after downloading.