---
title: "Middleware"
version: 2.0
locale: id
source: https://docs.djangoproject.com/id/2.0/topics/http/middleware/
canonical: https://djangodocs.dev/id/2.0/topics/http/middleware/
---
# Middleware

Middleware is a framework of hooks into Django's request/response processing.
It's a light, low-level "plugin" system for globally altering Django's input
or output.

Each middleware component is responsible for doing some specific function. For
example, Django includes a middleware component,
[`AuthenticationMiddleware`](/id/2.0/ref/middleware/#django.contrib.auth.middleware.AuthenticationMiddleware), that
associates users with requests using sessions.

This document explains how middleware works, how you activate middleware, and
how to write your own middleware. Django ships with some built-in middleware
you can use right out of the box. They're documented in the [built-in
middleware reference](/id/2.0/ref/middleware/).

## Menulis middleware anda sendiri

Pabrik middleware adalah sebuah callable yang mengambil callable `get_response` dan mengembalikan middleware. Middleware adalah callable yang mengambil permintaan dan mengembalikan tanggapan, seperti tampilan.

Sebuah middleware dapat ditulis sebagai sebuah fungsi yang terlihat seperti ini:

```
def simple_middleware(get_response):
    # One-time configuration and initialization.

    def middleware(request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.

        response = get_response(request)

        # Code to be executed for each request/response after
        # the view is called.

        return response

    return middleware
```

Atau itu dapat ditulis sebagai sebuah kelas yang instancenya callable, seperti ini:

```
class SimpleMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
        # One-time configuration and initialization.

    def __call__(self, request):
        # Code to be executed for each request before
        # the view (and later middleware) are called.

        response = self.get_response(request)

        # Code to be executed for each request/response after
        # the view is called.

        return response
```

Callable `get_response` disediakan oleh Django mungkin tampilan sebenarnya (jika ini adalah middleware terdaftar terakhir) atau itu mungkin menjadi middleware selanjutnya di rantai. Middleware sekarang tidak butuh mengetahui atau peduli apa sebenarnya itu, cukup bahwa itu mewakili apapun datang selanjutnya.

Diatas adalah sedikit penyerdahanaan -- callable `get_response` utnuk middleware akhir dalam rantai tidak akan berupa tampilan sebenarnya tetapi daripada sebuah metode pembungkus dari penangan yang menangani dari memberlakukan view middleware 1, memanggil tampilan dengan argumen-argumen URL sesuai, dan memberlakukan middleware template-response 2 dan exception 3.

Middleware dapat tinggal dimanapun pada jalur Python anda.

### `__init__(get_response)`

Middleware factories must accept a `get_response` argument. You can also
initialize some global state for the middleware. Keep in mind a couple of
caveats:

- Django initializes your middleware with only the `get_response` argument,
  so you can't define `__init__()` as requiring any other arguments.
- Unlike the `__call__()` method which is called once per request,
  `__init__()` is called only *once*, when the Web server starts.

### Menandai middleware sebagai tidak digunakan

It's sometimes useful to determine at startup time whether a piece of
middleware should be used. In these cases, your middleware's `__init__()`
method may raise [`MiddlewareNotUsed`](/id/2.0/ref/exceptions/#django.core.exceptions.MiddlewareNotUsed). Django will
then remove that middleware from the middleware process and log a debug message
to the [django.request](/id/2.0/topics/logging/#django-request-logger) logger when [`DEBUG`](/id/2.0/ref/settings/#std-setting-DEBUG) is `True`.

## Mengaktivasi middleware

Untuk mengaktifkan komponen middleware, tambah itu ke list [`MIDDLEWARE`](/id/2.0/ref/settings/#std-setting-MIDDLEWARE) dalam pengaturan Django anda.

In [`MIDDLEWARE`](/id/2.0/ref/settings/#std-setting-MIDDLEWARE), each middleware component is represented by a string:
the full Python path to the middleware factory's class or function name. For
example, here's the default value created by [`django-admin
startproject`](/id/2.0/ref/django-admin/#django-admin-startproject):

```
MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
```

A Django installation doesn't require any middleware — [`MIDDLEWARE`](/id/2.0/ref/settings/#std-setting-MIDDLEWARE)
can be empty, if you'd like — but it's strongly suggested that you at least use
[`CommonMiddleware`](/id/2.0/ref/middleware/#django.middleware.common.CommonMiddleware).

The order in [`MIDDLEWARE`](/id/2.0/ref/settings/#std-setting-MIDDLEWARE) matters because a middleware can depend on
other middleware. For instance,
[`AuthenticationMiddleware`](/id/2.0/ref/middleware/#django.contrib.auth.middleware.AuthenticationMiddleware) stores the
authenticated user in the session; therefore, it must run after
[`SessionMiddleware`](/id/2.0/ref/middleware/#django.contrib.sessions.middleware.SessionMiddleware). See
[Pengurutan middleware](/id/2.0/ref/middleware/#middleware-ordering) for some common hints about ordering of Django
middleware classes.

## Middleware order and layering

During the request phase, before calling the view, Django applies middleware in
the order it's defined in [`MIDDLEWARE`](/id/2.0/ref/settings/#std-setting-MIDDLEWARE), top-down.

You can think of it like an onion: each middleware class is a "layer" that
wraps the view, which is in the core of the onion. If the request passes
through all the layers of the onion (each one calls `get_response` to pass
the request in to the next layer), all the way to the view at the core, the
response will then pass through every layer (in reverse order) on the way back
out.

If one of the layers decides to short-circuit and return a response without
ever calling its `get_response`, none of the layers of the onion inside that
layer (including the view) will see the request or the response. The response
will only return through the same layers that the request passed in through.

## Other middleware hooks

Besides the basic request/response middleware pattern described earlier, you
can add three other special methods to class-based middleware:

### `process_view()`

#### `process_view(request, view_func, view_args, view_kwargs)`

`request` is an [`HttpRequest`](/id/2.0/ref/request-response/#django.http.HttpRequest) object. `view_func` is
the Python function that Django is about to use. (It's the actual function
object, not the name of the function as a string.) `view_args` is a list of
positional arguments that will be passed to the view, and `view_kwargs` is a
dictionary of keyword arguments that will be passed to the view. Neither
`view_args` nor `view_kwargs` include the first view argument
(`request`).

`process_view()` dipanggil sebelum Django memanggil tampilan.

It should return either `None` or an [`HttpResponse`](/id/2.0/ref/request-response/#django.http.HttpResponse)
object. If it returns `None`, Django will continue processing this request,
executing any other `process_view()` middleware and, then, the appropriate
view. If it returns an [`HttpResponse`](/id/2.0/ref/request-response/#django.http.HttpResponse) object, Django won't
bother calling the appropriate view; it'll apply response middleware to that
[`HttpResponse`](/id/2.0/ref/request-response/#django.http.HttpResponse) and return the result.

> **Note**
>
> Accessing [`request.POST`](/id/2.0/ref/request-response/#django.http.HttpRequest.POST) inside
> middleware before the view runs or in `process_view()` will prevent any
> view running after the middleware from being able to [modify the
> upload handlers for the request](/id/2.0/topics/http/file-uploads/#modifying-upload-handlers-on-the-fly),
> and should normally be avoided.
>
> The [`CsrfViewMiddleware`](/id/2.0/ref/middleware/#django.middleware.csrf.CsrfViewMiddleware) class can be
> considered an exception, as it provides the
> [`csrf_exempt()`](/id/2.0/ref/csrf/#django.views.decorators.csrf.csrf_exempt) and
> [`csrf_protect()`](/id/2.0/ref/csrf/#django.views.decorators.csrf.csrf_protect) decorators which allow
> views to explicitly control at what point the CSRF validation should occur.

### `process_exception()`

#### `process_exception(request, exception)`

`request` is an [`HttpRequest`](/id/2.0/ref/request-response/#django.http.HttpRequest) object. `exception` is an
`Exception` object raised by the view function.

Django calls `process_exception()` when a view raises an exception.
`process_exception()` should return either `None` or an
[`HttpResponse`](/id/2.0/ref/request-response/#django.http.HttpResponse) object. If it returns an
[`HttpResponse`](/id/2.0/ref/request-response/#django.http.HttpResponse) object, the template response and response
middleware will be applied and the resulting response returned to the
browser. Otherwise, [default exception handling](/id/2.0/ref/views/#error-views) kicks in.

Again, middleware are run in reverse order during the response phase, which
includes `process_exception`. If an exception middleware returns a response,
the `process_exception` methods of the middleware classes above that
middleware won't be called at all.

### `process_template_response()`

#### `process_template_response(request, response)`

`request` is an [`HttpRequest`](/id/2.0/ref/request-response/#django.http.HttpRequest) object. `response` is
the [`TemplateResponse`](/id/2.0/ref/template-response/#django.template.response.TemplateResponse) object (or equivalent)
returned by a Django view or by a middleware.

`process_template_response()` is called just after the view has finished
executing, if the response instance has a `render()` method, indicating that
it is a [`TemplateResponse`](/id/2.0/ref/template-response/#django.template.response.TemplateResponse) or equivalent.

It must return a response object that implements a `render` method. It could
alter the given `response` by changing `response.template_name` and
`response.context_data`, or it could create and return a brand-new
[`TemplateResponse`](/id/2.0/ref/template-response/#django.template.response.TemplateResponse) or equivalent.

You don't need to explicitly render responses -- responses will be
automatically rendered once all template response middleware has been
called.

Middleware are run in reverse order during the response phase, which
includes `process_template_response()`.

## Berurusan dengan aliran tanggapan

Unlike [`HttpResponse`](/id/2.0/ref/request-response/#django.http.HttpResponse),
[`StreamingHttpResponse`](/id/2.0/ref/request-response/#django.http.StreamingHttpResponse) does not have a `content`
attribute. As a result, middleware can no longer assume that all responses
will have a `content` attribute. If they need access to the content, they
must test for streaming responses and adjust their behavior accordingly:

```
if response.streaming:
    response.streaming_content = wrap_streaming_content(response.streaming_content)
else:
    response.content = alter_content(response.content)
```

> **Note**
>
> `streaming_content` should be assumed to be too large to hold in memory.
> Response middleware may wrap it in a new generator, but must not consume
> it. Wrapping is typically implemented as follows:
>
> ```
> def wrap_streaming_content(content):
>     for chunk in content:
>         yield alter_content(chunk)
> ```

## Penanganan pengecualian

Django automatically converts exceptions raised by the view or by middleware
into an appropriate HTTP response with an error status code. [Certain
exceptions](/id/2.0/ref/views/#error-views) are converted to 4xx status codes, while an unknown
exception is converted to a 500 status code.

Perubahan ini mengambil tempat sebelum dan setelah setiap middleware (anda dapat berpikir itu seperti film tipis dalam diantara setiap lapisan dari onion), sehingga setiap middleware dapat selalu bergantung pada mendapatkan sejenis tanggapan HTTP dari memanggil callable `get_response` nya. Middleware tidak butuh  khawatir tentang membungkus panggilan mereka pada `get_response` dalam sebuah `try/except` dan menangani sebuah pengecualian yang mungkin dimunculkan ole middleware akhir atau tampilan. Bahkan jika middleware berikutnya dalam rantai memunculkan sebuah pengecualian [`Http404`](/id/2.0/topics/http/views/#django.http.Http404), sebagai contoh, middleware anda tidak melihat pengecualian itu; bahkan itu akan mendapatkan sebuah obyek [`HttpResponse`](/id/2.0/ref/request-response/#django.http.HttpResponse) dengan sebuah [`status_code`](/id/2.0/ref/request-response/#django.http.HttpResponse.status_code) dari 404.

## Upgrading pre-Django 1.10-style middleware

#### `class django.utils.deprecation.MiddlewareMixin`

Django provides `django.utils.deprecation.MiddlewareMixin` to ease creating
middleware classes that are compatible with both [`MIDDLEWARE`](/id/2.0/ref/settings/#std-setting-MIDDLEWARE) and the
old `MIDDLEWARE_CLASSES`. All middleware classes included with Django
are compatible with both settings.

The mixin provides an `__init__()` method that accepts an optional
`get_response` argument and stores it in `self.get_response`.

Metode `__call__()`:

1. Memanggil `self.process_request(request)` (jika ditentukan).
2. Calls `self.get_response(request)` to get the response from later
   middleware and the view.
3. Memanggil `self.process_response(request, response)` (jika ditentukan).
4. Mengembalikan tanggapan

If used with `MIDDLEWARE_CLASSES`, the `__call__()` method will
never be used; Django calls `process_request()` and `process_response()`
directly.

In most cases, inheriting from this mixin will be sufficient to make an
old-style middleware compatible with the new system with sufficient
backwards-compatibility. The new short-circuiting semantics will be harmless or
even beneficial to the existing middleware. In a few cases, a middleware class
may need some changes to adjust to the new semantics.

These are the behavioral differences between using [`MIDDLEWARE`](/id/2.0/ref/settings/#std-setting-MIDDLEWARE) and
`MIDDLEWARE_CLASSES`:

1. Under `MIDDLEWARE_CLASSES`, every middleware will always have its
   `process_response` method called, even if an earlier middleware
   short-circuited by returning a response from its `process_request`
   method. Under [`MIDDLEWARE`](/id/2.0/ref/settings/#std-setting-MIDDLEWARE), middleware behaves more like an onion:
   the layers that a response goes through on the way out are the same layers
   that saw the request on the way in. If a middleware short-circuits, only
   that middleware and the ones before it in [`MIDDLEWARE`](/id/2.0/ref/settings/#std-setting-MIDDLEWARE) will see the
   response.
2. Under `MIDDLEWARE_CLASSES`, `process_exception` is applied to
   exceptions raised from a middleware `process_request` method. Under
   [`MIDDLEWARE`](/id/2.0/ref/settings/#std-setting-MIDDLEWARE), `process_exception` applies only to exceptions
   raised from the view (or from the `render` method of a
   [`TemplateResponse`](/id/2.0/ref/template-response/#django.template.response.TemplateResponse)). Exceptions raised from
   a middleware are converted to the appropriate HTTP response and then passed
   to the next middleware.
3. Under `MIDDLEWARE_CLASSES`, if a `process_response` method raises
   an exception, the `process_response` methods of all earlier middleware are
   skipped and a `500 Internal Server Error` HTTP response is always
   returned (even if the exception raised was e.g. an
   [`Http404`](/id/2.0/topics/http/views/#django.http.Http404)). Under [`MIDDLEWARE`](/id/2.0/ref/settings/#std-setting-MIDDLEWARE), an exception
   raised from a middleware will immediately be converted to the appropriate
   HTTP response, and then the next middleware in line will see that
   response. Middleware are never skipped due to a middleware raising an
   exception.