Giter VIP home page Giter VIP logo

django-userlog's Introduction

django-userlog

Goals

django-userlog is a lightweight solution to see in real-time how a given user is browsing a Django website. The intended use case is live customer support.

(Note that "synchronized browsing" is a much better solution. Modern live customer support solutions often provide this feature — if you can afford it!)

Requirements

This application requires Django ≥ 1.8 and Python ≥ 3.3 or 2.7. It uses a Redis server as storage backend.

Your website must be using Django's auth framework. The target user must be authenticated and you must be able to obtain their username. How you achieve this depends a lot on your project and on how you interact with the user.

Configuration

Install django-userlog and its dependencies in your project's virtualenv:

pip install django-userlog
pip install django-redis-cache hiredis redis

In order to use the live logs, you need some extra dependencies:

pip install asyncio_redis websockets
pip install asyncio                     # only for Python 3.3

If your project is running on Python ≥ 3.3, install everything in the same virtualenv. If your project requires Python 2.7, either you can live with the static logs, or you can create a separate virtualenv with Python ≥ 3.3 for the websockets server that powers the live logs.

Add 'userlog' to your INSTALLED_APPS setting.

Add 'userlog.middleware.UserLogMiddleware' to your MIDDLEWARE_CLASSES setting. It should come before any middleware that may change the response.

Configure a 'userlog' cache with django-redis-cache. (django-redis probably works too.) Define its TIMEOUT according to how long you want to preserve a user's log after his last request. You should select a dedicated Redis database or set a KEY_PREFIX to prevent clashes. Here's an example:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
    },
    'userlog': {
        'BACKEND': 'redis_cache.RedisCache',
        'LOCATION': 'localhost:6379',
        'TIMEOUT': 3600,
        'KEY_PREFIX': 'userlog',
    },
}

By default, django-userlog tracks no more than the latest 25 pages browsed by each user. You can adjust this value with the USERLOG_MAX_SIZE setting.

If you don't intend to use the live logs, set USERLOG_PUBLISH to False to decrease the workload of the Redis server.

You can exclude URLs from the logs by setting USERLOG_IGNORE_URLS to a list of regular expression patterns:

USERLOG_IGNORE_URLS = [
    r'^/favicon\.ico$',
]

In order to use the live logs, you must set the address of the websocket server:

USERLOG_WEBSOCKET_ADDRESS = 'ws://www.example.com:8080/'

Then you must run the websocket server at this address. The easiest solution is to set the DJANGO_SETTINGS_MODULE environment variable and run the userlog.realtime module:

DJANGO_SETTINGS_MODULE=myproject.settings python -m userlog.realtime

For more advanced use cases such as embedding the websocket server in an application or adding TLS, serve the userlog.realtime.userlog with the websockets library.

Usage

Open the Django admin. In the user logs section, choose between static logs or live logs. Enter a username in the search field. That's it!

image

Currently, only superusers can view user logs, for lack of a better solution.

FAQ

Why use Django's caching infrastructure to connect to Redis?

It's the easiest way to obtain a properly managed connection to Redis, including connection pooling.

Hacking

If you want to suggest changes, please submit a pull request!

This repository includes a sample project. To try it, clone the repository, create a virtualenv and run these commands:

pip install -r requirements.txt
pip install -e .
DJANGO_SETTINGS_MODULE=userlog.example_settings django-admin.py migrate
DJANGO_SETTINGS_MODULE=userlog.example_settings django-admin.py runserver

Once this basic setup is done, there's a shortcut to start the server:

make example

And another one to start the websocket server:

make realtime

Run the tests:

make test

Compute test coverage:

make coverage

Check your coding stye:

make flake8

License

django-userlog is released under the BSD license, like Django itself.

django-userlog's People

Contributors

aaugustin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

django-userlog's Issues

Handle unauthenticated users

Currently userlog only works for logged-in users.

There might be a use case for anonymous users. That would require logging requests by session id (easy) and finding a way to recover the session id (not obvious).

The session id could be obtained by sending the user to a specific view that would store the association between a known value and the session id in Redis.

Errors may not be logged

There are at least two cases where an HTTP request will fail and not be logged:

  1. If the view function hangs or gets killed somehow, possibly because the application server enforces a timeout.

    To avoid that problem, I could log requests in process_request and update the log in process_response. However that increases the overhead from one to two cache writes per HTTP request for limited benefits.

    I don't think userlog should focus on error handling. That's the realm of Sentry.

  2. If response middleware that runs before the userlog middleware raises an exception.

    The userlog middleware must run as late as possible because other response middleware may change the response's status code. If an exception happens in an earlier middleware, the only way for userlog to catch it is to connect to the got_request_exception signal. It's not obvious that this would be a good idea.

    I'm willing to accept this as a known limitation and push the responsibility to flaws in the design or the implementation of Django's middleware API.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.