rhumbix/django-request-logging

Django middleware that logs http request body.

django-request-logging

Plug django-request-logging into your Django project and you will have intuitive and color coded request/response payload logging, for both web requests and API requests. Supports Django 1.8+.

Installing

$ pip install django-request-logging

Then add request_logging.middleware.LoggingMiddleware to your MIDDLEWARE.

For example:

MIDDLEWARE = (
    ...,
    'request_logging.middleware.LoggingMiddleware',
    ...,
)

And configure logging in your app:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
        },
    },
    'loggers': {
        'django.request': {
            'handlers': ['console'],
            'level': 'DEBUG',  # change debug level as appropiate
            'propagate': False,
        },
    },
}

Details

Most of the times you don't have to care about these details. But in case you need to dig deep:

• All logs are configured using logger name "django.request".
• If HTTP status code is between 400 - 599, URIs are logged at ERROR level, otherwise they are logged at INFO level.
• If HTTP status code is between 400 - 599, data are logged at ERROR level, otherwise they are logged at DEBUG level.

See REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL setting to override this.

A no_logging decorator is included for views with sensitive data. This decorator allows control over logging behaviour of single views via the following parameters:

* value
    * False: the view does NOT log any activity at all (overrules settings of log_headers, log_body, log_response and automatically sets them to False).
    * True: the view logs incoming requests (potentially log headers, body and response, depending on their specific settings)
    * None: NO_LOGGING_DEFAULT_VALUE is used (can be defined in settings file as DJANGO_REQUEST_LOGGING_NO_LOGGING_DEFAULT_VALUE)
* msg
    * Reason for deactivation of logging gets logged instead of request itself (only if silent=True and value=False)
    * NO_LOGGING_MSG is used by default
* log_headers
    * False: request headers will not get logged
    * True: request headers will get logged (if value is True)
    * None: LOG_HEADERS_DEFAULT_VALUE is used (can be defined in settings file as DJANGO_REQUEST_LOGGING_LOG_HEADERS_DEFAULT_VALUE)
* no_header_logging_msg
    * Reason for deactivation of header logging gets logged instead of headers (only if silent=True and log_headers=False)
    * NO_HEADER_LOGGING_MSG is used by default
* log_body
    * False: request body will not get logged
    * True: request headers will get logged (if value is True)
    * None: LOG_BODY_DEFAULT_VALUE is used (can be defined in settings file as DJANGO_REQUEST_LOGGING_LOG_BODY_DEFAULT_VALUE)
* no_body_logging_msg
    * Reason for deactivation of body logging gets logged instead of body (only if silent=True and log_body=False)
    * NO_BODY_LOGGING_MSG is used by default
* log_response
    * False: response will not get logged
    * True: response will get logged (if value is True)
    * None: LOG_RESPONSE_DEFAULT_VALUE is used (can be defined in settings file as DJANGO_REQUEST_LOGGING_LOG_RESPONSE_DEFAULT_VALUE)
* no_response_logging_msg
    * Reason for deactivation of body logging gets logged instead of body (only if silent=True and log_body=False)
    * NO_RESPONSE_LOGGING_MSG is used by default
* silent
    * True: deactivate logging of alternative messages case parts of the logging are deactivated (request/header/body/response)
    * False: alternative messages for deactivated parts of logging (request/header/body/response) are logged instead

By default, value of Http headers HTTP_AUTHORIZATION and HTTP_PROXY_AUTHORIZATION are replaced wih *****. You can use REQUEST_LOGGING_SENSITIVE_HEADERS setting to override this default behaviour with your list of sensitive headers.

Django settings

You can customized some behaves of django-request-logging by following settings in Django settings.py.

REQUEST_LOGGING_DATA_LOG_LEVEL

By default, data will log in DEBUG level, you can change to other valid level (Ex. logging.INFO) if need.

REQUEST_LOGGING_ENABLE_COLORIZE

It's enabled by default. If you want to log into log file instead of console, you may want to remove ANSI color. You can set REQUEST_LOGGING_ENABLE_COLORIZE=False to disable colorize.

REQUEST_LOGGING_DISABLE_COLORIZE (Deprecated)

This legacy setting will still available, but you should't use this setting anymore. You should use REQUEST_LOGGING_ENABLE_COLORIZE instead. We keep this settings for backward compatibility.

REQUEST_LOGGING_MAX_BODY_LENGTH

By default, max length of a request body and a response content is cut to 50000 characters.

REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL

By default, HTTP status codes between 400 - 499 are logged at ERROR level. You can set REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL=logging.WARNING (etc) to override this. If you set REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL=logging.INFO they will be logged the same as normal requests.

REQUEST_LOGGING_SENSITIVE_HEADERS

The value of the headers defined in this settings will be replaced with '*****' to hide the sensitive information while logging. By default it is set as REQUEST_LOGGING_SENSITIVE_HEADERS = ["HTTP_AUTHORIZATION", "HTTP_PROXY_AUTHORIZATION"]

DJANGO_REQUEST_LOGGING_LOGGER_NAME

Name of the logger that is used to log django.request occurrances with the new LoggingMiddleware. Defaults to "django.request".

DJANGO_REQUEST_LOGGING_NO_LOGGING_DEFAULT_VALUE

Global default to activate/deactivate logging of all views. Can be overruled for each individual view by using the @no_logging decator's "value" parameter.

DJANGO_REQUEST_LOGGING_LOG_HEADERS_DEFAULT_VALUE = True

Global default to activate/deactivate logging of request headers for all views. Can be overruled for each individual view by using the @no_logging decator's "log_headers" parameter.

DJANGO_REQUEST_LOGGING_LOG_BODY_DEFAULT_VALUE = True

Global default to activate/deactivate logging of request bodys for all views. Can be overruled for each individual view by using the @no_logging decator's "log_body" parameter.

DJANGO_REQUEST_LOGGING_LOG_RESPONSE_DEFAULT_VALUE = True

Global default to activate/deactivate logging of responses for all views. Can be overruled for each individual view by using the @no_logging decator's "log_response" parameter.

Deploying, Etc.

Maintenance

Use pyenv to maintain a set of virtualenvs for 2.7 and a couple versions of Python 3. Make sure the requirements-dev.txt installs for all of them, at least until we give up on 2.7. At that point, update this README to let users know the last version they can use with 2.7.

Setup

• pip install twine pypandoc pbr wheel
• If pypandoc complains that pandoc isn't installed, you can add that via brew if you have Homebrew installed
• You will need a .pypirc file in your user root folder that looks like this:

    index-servers=
        testpypi
        pypi

    [testpypi]
    username = rhumbix
    password = password for [email protected] at Pypi

    [pypi]
    username = rhumbix
    password = password for [email protected] at Pypi

Publishing

• Bump the version value in request_logging/__init__.py
• Run python setup.py publish
• Manually tag per the instructions in the output of that command
• TODO: add automagic git tag logic to the publish process
• TODO: setup 2FA at Pypi

django-request-logging's Issues

No mean no...even for headers and responses

We still log headers and responses even when a method has the annotation "no_logging". We should probably make a request silent if that is the case.

400-499 responses should not be logged as ERROR

Only requests in the 500-599 represent errors.
400-499 are very legitimate response codes to use when handling error and are therefore not errors.

formator [User: {request.user}] work with runserver but not while running asychronously

gunicorn project.asgi:application -k uvicorn.workers.UvicornWorker --bind 0.0.0.0:8000

Formatting field not found in record "request"

Does not support Django 3.2

I am working on a PR to add Django 3.2 support, could you please merge #116 first so I can fix tests properly afterwards?

sensitive_post_parameters not honored

Hello,

Given that some libraries use the native sensitive_post_parameters decorator as opposed to the no_logging decorator that is specific to this library I am proposing that functionality is added to honor the sensative_post_parameters decorator as described here, https://docs.djangoproject.com/en/2.2/howto/error-reporting/#django.views.decorators.debug.sensitive_post_parameters

Logging of request/response headers

AttributeError: 'JsonResponse' object has no attribute '_headers'

Internal Server Error: /backend/api/sysInfo
Traceback (most recent call last):
  File "C:\Test_Installation\pythonEnvironmentWithAllStuff\lib\site-packages\django\core\handlers\exception.py", line 47, in inner
    response = get_response(request)
  File "C:\Test_Installation\pythonEnvironmentWithAllStuff\lib\site-packages\request_logging\middleware.py", line 106, in __call__
    self.process_response( request, response )
  File "C:\Test_Installation\pythonEnvironmentWithAllStuff\lib\site-packages\request_logging\middleware.py", line 207, in process_response
    self._log_resp(self.log_level, response, logging_context)
  File "C:\Test_Installation\pythonEnvironmentWithAllStuff\lib\site-packages\request_logging\middleware.py", line 254, in _log_resp
    self.logger.log(level, response._headers, logging_context)
AttributeError: 'JsonResponse' object has no attribute '_headers'

Is this because Django 3.2 or rest_framework?

Please release version 0.5.3 onto Python Package Index

Currently v0.5.2 exists, and I'd like the same for 0.5.3 (specifically looking to use #22 feature for our application). @tclancy

How do I use the no_logging decorator?

Hi All,

Could anyone tell me how do I use the no_logging decorator?

I am not able to retrieve the correct function name from the following piece of code:

    def _should_log_route(self, request):
        # request.urlconf may be set by middleware or application level code.
        # Use this urlconf if present or default to None.
        # https://docs.djangoproject.com/en/2.1/topics/http/urls/#how-django-processes-a-request
        # https://docs.djangoproject.com/en/2.1/ref/request-response/#attributes-set-by-middleware
        urlconf = getattr(request, "urlconf", None)

        try:
            route_match = resolve(request.path, urlconf=urlconf)
        except Resolver404:
            return False, None

        method = request.method.lower()
        view = route_match.func
        func = view
        # This is for "django rest framework"
        if hasattr(view, "cls"):
            if hasattr(view, "actions"):
                actions = view.actions
                method_name = actions.get(method)
                if method_name:
                    func = getattr(view.cls, view.actions[method], None)
            else:
                func = getattr(view.cls, method, None)
        elif hasattr(view, "view_class"):
            # This is for django class-based views
            func = getattr(view.view_class, method, None)
        no_logging = getattr(func, NO_LOGGING_ATTR, False)
        return no_logging

And my no_logging function looks like this:

def no_logging():
    def wrapper(func):
        setattr(func, NO_LOGGING_ATTR, True)
        return func
    return wrapper

Note: I removed the NO_LOGGING_MSG_ATTR as I did not need that, correspondingly I made changes and removed the because variable in the remaining functions too.

I am using DRF view classes which have a few arguments.

The func evaluates to be one of the argument and not the class itself for which reason, the getattr is not able to retrieve NO_LOGGING_ATTR.

My use case is this:

@no_logging()
class MapImageViewSet(arg1, RetrieveModelMixin, UpdateModelMixin):

The func in above should_log_route class evaluates to be <function RetrieveModelMixin.retrieve at 0x7f8986b91940>.

Can someone tell if I am using the no_logging decorator correctly or there is some error in evaluating the func in the should_log_route function?

Thanks

EDIT:

So, I figured out the class we are decorating the @no_logging func with should be a view class.
And view.cls gets us the complete class name so we can retrieve the attribute set by our no_logging can be retrieved by using:

no_logging = getattr(view.cls, NO_LOGGING_ATTR, False)

The above is true for DRF use cases.
Didn't understand why are we trying to retrieve the method and stuff.
Any explanation is greatly appreciated.

Does this support easily logging to a database?

If so, can you point me to a description, or describe?

Thanks for your work on this project.

no_logging seems not to work for Class Based Views (CBVs)?

Can't seem to get no_logging to work.

I've tried as below but I still see passwords being logged. Am using rest_framework_simplejwt so to obtain a token I use the TokenObtainPairView

from rest_framework_simplejwt.views import TokenObtainPairView
from django.utils.decorators import method_decorator

class MyTokenObtainPairView(TokenObtainPairView):
    serializer_class = MyTokenObtainPairSerializer

    @method_decorator(no_logging())
    def dispatch(self, *args, **kwargs):
        return super().dispatch(*args, **kwargs)

Log Shows:
2019-11-09 11:18:15 [DEBUG] b'{\n "email": "[email protected]",\n "password": "full-password"\n}'

App Versions:
django==2.2.2
djangorestframework==3.9.4
django-request-logging==0.7.0

What if I want to write the logs in a .txt file

Right now it's printing on the console, what if I want to pipe the logs in a file.?

DATA_UPLOAD_MAX_MEMORY_SIZE in Middleware

I don't want to add the DATA_UPLOAD_MAX_MEMORY_SIZE in my settings.py but because of using the middleware. Now response in Django app is directing me that I have exceeded the MAX_MEMORY_SIZE while uploading the files. I don't want to set any max memory size in my app for now. Is there some way to use this middleware and still upload a larger file.

Travis CI support

As they say, to test and deploy with confidence :)

Is it possible to add Color logs only for some handlers

Is it possible to add Color logs only for some handlers, like console, and exclude for others like file,

or can you provide Formatter that will clean logs correctly

class FileOutputFormatter(logging.Formatter):
def format(self, record):
msg = super().format(record)
color_prefix = "\0%s["
color_suffix = '\0[0m'
colors = range(30, 42)
for color in colors:
msg = msg.replace(color_prefix % color, "").replace(color_suffix % color, "")

    return msg

No git tag for 0.6.8 release

Thanks

tests are failing

It looks like tests that expects the body in the logs does not found it and fail: e.g. AssertionError: 'some body' not found in "\x1b[36mPOST /a-missing-route-somewhere\x1b[0m\x1b[36m{'HTTP_COOKIE': ''}\x1b[0m"

The fail both in travis (https://travis-ci.com/github/xrmx/django-request-logging/builds/202324399) and locally with python3.8 and django 2.2 / 3.0 / 3.1.

[question/docs] Supported versions of django

Hello, thanks for this cool middleware. What versions of django is this compatible with? Can you please add it to README.md?

Support Opt-In behaviour for logging requests

Requests logging opt-in

I have a number of services that have certain endpoints that we would love to use request logging for, but, they also contain a number of endpoints that are much more "spammy" and we don't really get a benefit from emitting logs for each request. What would your thoughts be on updating the framework to support a setting making request logging opt-in. Something like

REQUEST_LOGGING_DEFAULT_OPT_IN: bool = True  # By default opt in to all requests being logged

Then, a decorator could be used like opt_in_to_logging(silent=True), which could raise an error if REQUEST_LOGGING_DEFAULT_OPT_IN is true

Misc

• It would also be really nice to be able to globally specify silent=False on no_logging - I wouldn't mind implementing this!
  • It might be nice to call out that by default setting no_logging will still generate a log message too
• I really like packages like this for these types of operations, I was going to hand roll this code and the implementation here is just much nicer to use
  • Anything that I pitch here I'd 100% be down to contribute, I just want to avoid writing code for features that aren't actually wanted within the library

[Questions] Is it okay to send a PR with following features?

Hi there,

I tried to use this package in our django server, but I need some customizations. I can tried to help to implement those features and send a PR. However, I just want to confirm if those features is acceptable for you~?

Features

1. Use Django settings to change default log level from DEBUG to another level
   Reason: May root logging handle set logging level to INFO and it looks like those logs in DEBUG level won't appear in my log file. Therefore, I need a setting to change default log level to INFO.
2. Use Django settings to disable colorize
   Reason: We didn't need ANSI graphics codes in log file.

(question) is there a way to use this logger in production with uwsgi?

1. Is this an ok (maybe performance wise as opposed to using uwsgi logging) to use this logger in production?

2. I can see the log in runserver but not with uwsgi setup. Is there something special I need to do see the logs in production setup (with nginx/uwsgi)

     'loggers': {

        'django.request': {
             'handlers': ['console'],
             'level': 'INFO',  # change debug level as appropiate
             'propagate': False,
         },

Log level settings should accept strings (eg "INFO")

For consistency with Python's logging config (and to avoid having to import logging into settings), we should probably allow the REQUEST_LOGGING_DATA_LOG_LEVEL and REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL settings to be set as strings ("INFO" etc) as well as the enum values from logging (logging.INFO etc).

Add support for unicode literals?

First of all, thanks for this amazing middleware!

While I was using, there were situations to log Korean request and/or response entities.
However, I realized that this middleware logs unicode literals "as is", not decoded into its natural characters. (i.e. Korean, Chinese, etc.)

Wouldn't it be nice if I can add supports for those unicode literals?

Django 2+ support

Currently tests will not execute due to dependency failures with Django 2.0, the currently supported version.

Handling of StreamingHTTPResponses

Currently, the case that a response is a django.http.StreamingHttpResponse (instead of a django.http.HttpResponse doesn't seem to be covered.
This leads to an AttributeError in the LoggingMiddleware._log_resp method (and a 500 Http status code) because response.content is accessed, but StreamingHttpResponse objects don't have that attribute, but a stream_content instead.
If you're generally ready to accept a PR adding proper handling of StreamingHttpResponse, let me know, add I'll try to put one together.

log created timestamp in log file

Hello Team,
This is a wonderful plugin and i need to log created time along with request data so i need support to use formatters with your plugin.

Thanks

Show clear text password

I tried this product but it show clear text password in console log

please recommend the MIDDLEWARE setting

MIDDLEWARE_CLASSES are deprecated. Please explain the middleware using MIDDLEWARE.
Elsewise people will be surprised if the middleware stops working.

Log all response content option?

I noticed that response content is logged only if content type is application/json. Would it be possible to add an option for logging all response content?

document response logging

Please document in the readme that this middleware can also log responses.
I had to look up the code to see this features ( I need this feature)

body encoding

I hit a problem using Python 3 and sending an image file to the server:

  File "/data/project/venv/lib/python3.5/site-packages/request_logging/middleware.py", line 132, in _log_multipart
    body_str = body if isinstance(body, str) else body.decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 573: invalid start byte

There should be a global try-except to avoid any APP crash at all due to request-logging.

Request and Response in One Line Log Format

Currently, for every request, the logger will log both request and response URL, headers, and body as a separate line. There some cases that the log will not be in the right sequence if there are multiple requests at one time.
Is there some way to have the log in one line format (each line of a log includes request and response data) using this middleware?

Replace data like password with asterisks

Log request headers and body at 4xx level when response status is >= 400

Hello, and thanks for the good work! We use and love your package but we do have one problem with it.

We would definitely like to have headers and body of failing requests (status >= 400) to be logged at the level set in settings.REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL.

Current behavior

class LoggingMiddleware(object):
    def __call__(self, request):
        self.process_request(request)
        response = self.get_response(request)
        self.process_response(request, response)
        return response

The middleware:

1. Logs incoming request.
2. Lets the response be processed by Django.
3. Logs the response.

This design makes it impossible to log request headers/body at different levels depending on response status code, because, well, response does not exist yet at the time.

Proposed behavior

Logging both request AND response after response has been processed, allowing customization of log level on both the request and its response.

We would happily offer a pull request for this change :-)

Can we log the time like in Django standard login?

If I develop Django and login it logs:
[28/May/2021 16:11:50] "POST /backend/api/login HTTP/1.1" 200 171

But if I host Django using WSGI and use your library it logs:

POST /backend/api/login
POST /backend/api/login - 200

• Is there an option to enable time logging? And if not, would it be possible that you make one?
• I think it is enough to log one line in this case like the django original logger does.

Import Error MiddlewareMixin

Django==1.8
django-extensions==1.7.8

ImportError: cannot import name MiddlewareMixin

RawPostDataException with 0.6.8

We see this error when doing a post after upgrading from 0.6.7 to 0.6.8:

/request_logging/middleware.py:166: in process_body
@property
    def body(self):
        if not hasattr(self, '_body'):
            if self._read_started:
>               raise RawPostDataException("You cannot access body after reading from request's data stream")
E               django.http.request.RawPostDataException: You cannot access body after reading from request's data stream

using django 2.2.1

A way to disable logging for certain attributes of payload like password

There should be a way to blacklist certain keywords (like password) to not logged.

Error format in log and how to add time query execute

i have issue when log it to file: My log like it:

^[[36m{'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36', 'HTTP_HOST': 'localhost:8000', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate, br',$ ^[[36mGET /swagger/ - 200^[[0m ^[[36mGET /swagger/?format=openapi^[[0m

How to remove ^[[36m and ^[[0m in my log file?

My config :
LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'file': { 'level': 'DEBUG', 'class': 'logging.FileHandler', 'filename': '/var/log/app-logs/django.log', }, }, 'loggers': { 'django.request': { 'handlers': ['file'], 'level': 'DEBUG', 'propagate': True, } } }

I want add time query execute for check log better. How to add it? I cant find a way do it in google.

Thanks!

Issue when run asynchronously

`Formatting field not found in record: 'request'

File "/home/xxx/.cache/pypoetry/virtualenvs/backend-0jntSMg_-py3.8/lib/python3.8/site-packages/django/core/handlers/base.py", line 122, in adapt_method_mode
logger.debug('Asynchronous %s adapted.', name)
Message: 'Asynchronous %s adapted.'
Arguments: ('middleware request_logging.middleware.LoggingMiddleware',)

gunicorn project.asgi:application -k uvicorn.workers.UvicornWorker --bind 0.0.0.0:8000`

both `(request and response)` logs are called after `self.get_response`

In the below code both (request and response) logs are called after self.get_response

I want to see the request logging first and then the some logging in my views and then the reponse logging.

This is a bit of confusion.

    def __call__(self, request):
        self.cached_request_body = request.body
        response = self.get_response(request)
        self.process_request(request,response)
        self.process_response(request, response)
        return response

Unable to use `no_logging` on admin login view

I'm trying to avoid logging the login request for the default django admin site, since it contains a password in the request body. Is there a way to apply the no_logging decorator to an arbitrary view?

I tried manually setting the NO_LOGGING_ATTR on django.contrib.admin.sites.login (source) which is passed as the view/func to _should_log_route like so:

from django.contrib.admin.sites import site

from request_logging.middleware import NO_LOGGING_ATTR, NO_LOGGING_MSG_ATTR

def no_log_admin_login():
    setattr(site.login, NO_LOGGING_ATTR, True)
    setattr(site.login, NO_LOGGING_MSG_ATTR, "Admin login view contains password")

but this fails with AttributeError: 'method' object has no attribute 'no_logging'

Given how invasive this kind of patch is in general, I'm not sure I'd be happy even if I could get it to work...

So, I was wondering if you would be open to a new setting like REQUEST_LOGGING_SKIP_ROUTES which would contain a list of routes like ['/admin/login/', '/api/sensitive/'], which could be checked in _should_log_route in addition to the NO_LOGGING_ATTR. I feel this would be useful in general for controlling how logging is done for third party views/apps

Empty HTTP requests get logged after commit 9bfe9c99bc524c466458f5c8cbf516e8e1f97cd2 (8/28/2020)

We are users of this package, thank you, and we recently bumped to the latest version as part of a larger upgrade effort.

Everything still works well, however we noticed that we have a lot of log entries with and empty message, for HTTP requests with no body.

ERROR|P|2021-07-17 18:43:25,185|3698|140577588385536|31e1c60a-aad0-457b-a49c-2ac47661353f|middleware|log|b''

I did some review of the code and I noticed that as part of commit 9bfe9c9 , _log_request_body changed the test of the body from:

if request.body:

to

if self.cached_request_body is not None:

Which means that the code now logs empty request bodies.

Do you know if this change was intentional to actually log empty bodies or is it an oversight form the change to using cached_request_body rather than body?

If you agree that this was an unintended change, I'm happy to consider a fix and create a pull request for the change.

I did a small test changing the line from:

if self.cached_request_body is not None:

to

if self.cached_request_body:

And the behaviour now matches the one pre commit on 8/28/2020.

Let me know if I can help.

deprecation warning

https://github.com/Rhumbix/django-request-logging/blob/master/request_logging/middleware.py#L5

The import should be reversed to avoid a deprecation warning with Django 1.11, it should read:

try:
    # Django 2.x
    from django.urls import Resolver404
except ImportError:
    # Django 1.x
    from django.core.urlresolvers import Resolver404

Probably both try/except blocks could be merged.

Dependabot couldn't authenticate with https://pypi.python.org/simple/

Dependabot couldn't authenticate with https://pypi.python.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

Move CI Tests to Github Actions

See docs for reference, would be nice to move off of Travis.

Problem logging URI

In the documentation it is stated that:

If HTTP status code is between 400 - 599, URIs are logged at ERROR level, otherwise they are logged at INFO level.
If HTTP status code is between 400 - 599, data are logged at ERROR level, otherwise they are logged at DEBUG level.

But when you look at the code:

def process_request(self, request):
        method_path = "{} {}".format(request.method, request.get_full_path())
        logging_context = self._get_logging_context(request, None)
        self.logger.log(logging.INFO, method_path, logging_context)

method_path should also be logged if there is an error at the ERROR level is't it?

django.core.exceptions.ImproperlyConfigured: 'request_logging.middleware.LoggingMiddleware' isn't a subclass of AppConfig.

Hi,
Tried to add this middleware, but got an error:

Traceback (most recent call last):
  File "C:\Test_Installation\Test\psbp\resource\server\bpServer3\manage.py", line 22, in <module>
    main()
  File "C:\Test_Installation\Test\psbp\resource\server\bpServer3\manage.py", line 18, in main
    execute_from_command_line(sys.argv)
  File "C:\Test_Installation\pythonEnvironmentWithAllStuff\lib\site-packages\django\core\management\__init__.py", line 419, in execute_from_command_line
    utility.execute()
  File "C:\Test_Installation\pythonEnvironmentWithAllStuff\lib\site-packages\django\core\management\__init__.py", line 395, in execute
    django.setup()
  File "C:\Test_Installation\pythonEnvironmentWithAllStuff\lib\site-packages\django\__init__.py", line 24, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "C:\Test_Installation\pythonEnvironmentWithAllStuff\lib\site-packages\django\apps\registry.py", line 91, in populate
    app_config = AppConfig.create(entry)
  File "C:\Test_Installation\pythonEnvironmentWithAllStuff\lib\site-packages\django\apps\config.py", line 229, in create
    raise ImproperlyConfigured(
django.core.exceptions.ImproperlyConfigured: 'request_logging.middleware.LoggingMiddleware' isn't a subclass of AppConfig.

Process finished with exit code 1

Request.user

Request headers should include request user and ip address. It helps the aim of logging.

Exclude/Include certain views for logging

It would be nice to have a setting where a user can define which views he/she wants logged. And if they are to be logged, would it be requests, responses or both.

For instance, we have some views which should not be logged for security reasons, so i would like to exclude them from logging the response or request.

This could work similar to how DRF handles throttling per view. Something like:

LOGGING_ENABLED_FOR: {
    'customer_actions': 'response',
    'customer_auth': None,
    'customer_orders': 'request'
 }