Hi @philippeowagner,

Let me start by expressing my gratitude towards the hours you and other contributors have sunk into this project. With that in mind, it would be sad to see this library fade away. Looking that the current state of the repository, it might be time to consider putting this project under new maintainership, to fuel the project with new enthusiasm.

Since you are a @jazzband member yourself, that would certainly be an option. If you prefer a corporate or individual maintainer, that could also be arranged.

Maybe you find the time to share your thoughts.

Best, Joe

Bumped into a case where request is None when trying to show a render a template error message after an uncaught exception elsewhere in the application, resulting in another exception in hijack_tags.py. The changes in this pull request handle this by checking for request==None and request.session==None before trying to get the session attributes.

I am using the builtin django auth signal user_logged_in to record when user logins and store metadata about their login. However, I do not want to keep track of hijacked logins. This presents an issue because at the point a user is logged in via hijack https://github.com/arteria/django-hijack/blob/master/hijack/helpers.py#L110, the session variables are not set, which does make sense since you wouldn't want to set session variables before a login completely succeeds.

Perhaps, there could be some other session variable set at the beginning of the login_user method that would give an indication that the user's login is being handled from django-hijack.

@philippeowagner We should probably discuss the changes outside of Github. I wrote you in KeyBase. My package on test.pypi https://test.pypi.org/project/django-hijack/

=== (3.0.0) ===

• Drop support for python<3.5
• Drop support for Django<2.2
• Big code refactoring
• CI improvements, automatically pypi deploy
• Added wheel for pypi build

Hello! Thanks for making hijack. Been using it on my site, but we just switched most of our main pages to using django-jinja for template rendering and thought that you might like to have in the system the code we needed to use to get the tag to work.

Writing a Jinja2 extension is very difficult, and there were no documented examples I could find of how to write an extension that required the request object, so I implemented it as a filter on the request object. So in place of {% hijack_notification %} I used {{ request|hijack_filter }} and then made an entry in jinja_filters.py like so:

import django
from django.template.loader import render_to_string
from django.utils.safestring import mark_safe
from django_jinja import library 
from hijack import settings as hijack_settings

@library.filter
def hijack_filter(request):
    if hijack_settings.HIJACK_USE_BOOTSTRAP: 
        template_name = 'hijack/notifications_bootstrap.html'
    else:
        template_name = 'hijack/notifications.html'
    ans = ''
    if request is not None and all([
        hijack_settings.HIJACK_DISPLAY_WARNING,
        request.session.get('is_hijacked_user', False),
        request.session.get('display_hijack_warning', False),
    ]):
        if django.VERSION < (1, 8):
            from django.template import RequestContext
            ans = render_to_string(template_name, context_instance=RequestContext(request))
        else:
            ans = render_to_string(template_name, request=request)
    return mark_safe(ans)

in config.settings in the TEMPLATES setting for django_jinja.backend.Jinja2 under OPTIONS add a dict:

"filters": {
                "hijack_filter": 'myapp.utilities.jinja_filters.hijack_filter',
           },

Hope that this is helpful to others or can become a part of the default hijack installation.

Simplify URL and view structure. Add support for multiple PK types based on URL pattern as well as natural key support via URL patterns.

Changes:

• Deprecate HIJACK_URL_ALLOWED_ATTRIBUTES setting favoring HIJACK_USER_URL_PATTERN.
• Deprecate URL names login_with_id, login_with_username and login_with_email favoring acquire.
• Deprecate URL name release_hijack favoring release.
• Deprecate views login_with_id, login_with_username and login_with_email favoring release_user_view.
• Deprecate view release_hijack favoring release_user_view.

Close #196 Close #183 Close #184 Close #198 Close #147 Close #175

After installing the module on the site. Began to notice that some users see some pages of other users. How to fix this? Django: 2.0.1 Python 3.6.4 django-hijack: 2.1.6 django-hijack-admin: 2.1.6

The middleware's process_response method uses regex to parse the HTML response and inject content.

This is easily broken, leading to the content being injected in the wrong place or not at all.

I will open a PR with unit tests showing this.

See this stackoverflow post as to why parsing HTML with regex is a bad idea.

The old design was based on a lot of untested behavior that has since been included in Django itself, including proper testing and security oversight.

This refactoring uses those new tools and aims to greatly simplify the overall design. This simplification should keep potential exposior to a minimum.

As a result almost all settings have been dropped, infavor of a simple permission callback and a notification template. Both can be overriden in a users application to customize behavior as need.

The documenation is completly rewritten too. It may server as a good starting point to understand this change.

Changes in a nutshell:

• Add Material style snackback notification
• Use permission callbacks instead of settings
• Provide permission callback for convenience
• Render and inject notification via middleware
• Use Django class based views and mixins for permission handling
• Update the documentation to reflect new design
• Compile gettext messages during release
• Switch to SCSS and compile during release
• Add msgcheck linter for translations
• Add styleling as a SCSS linter
• Update translations

I'm not sure what casting the user_id as an int is meant to accomplish in views.py, but on one of my projects the user_id is not always an integer and I noticed I was unable to hijack these users.

Removing lines 16-20 fixes my issue and doesn't appear to have adverse effects. It would also address these issues https://github.com/arteria/django-hijack/issues/183 and https://github.com/arteria/django-hijack/issues/196.

The form markup provided in the documentation doesn't work [1], working code is in the test project [2] though when modified.

[1] https://django-hijack.readthedocs.io/en/stable/#usage [2]: https://github.com/django-hijack/django-hijack/blob/master/hijack/tests/test_app/templates/user_list.html

Greetings!

We have a pretty standard django-hijack setup and most of the times it just works. However, we are noticing in Sentry a flaky hijjack issue:

KeyError: 'CSRF_COOKIE'
  File "django/core/handlers/exception.py", line 55, in inner
    response = get_response(request)
  File "django/utils/deprecation.py", line 136, in __call__
    response = self.process_response(request, response)
  File "hijack/middleware.py", line 47, in process_response
    {"request": request, "csrf_token": request.META["CSRF_COOKIE"]},

So, the library is trying to access CSRF cookie from request.META, but it is not available in the given <WSGIRequest: GET '/'> instance.

hijack.middleware.HijackUserMiddleware is placed after the CSRF one:

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
    ...
    "hijack.middleware.HijackUserMiddleware",
]

Sadly, I am still not able to reproduce it. I only can suspect that in certain pages when we are redirecting after hijacking there is no CSRF token set from template. Do you have any ideas on this, maybe hints?

I am happy to prepare a patch here or will wait for your solution.

Best, Rust

My org is using django-hijack to allow staff to masquerade as users. We've noticed that our staff users sometimes forget to release the hijack when they're done, and there's been a request to automatically release the hijack after a set time has elapsed. Reviewing the documentation, I see no provision for such a feature.

More precisely, I'd like to add a setting HIJACK_TIMEOUT_SECONDS, defaulting to None. If the setting has a non-null value, that value is the number of seconds from start of hijack before automatic release of the user. Typical value expected to be on the order of six hours.

Is this a feature that the django-hijack maintainers would be interested in seeing? If so, we'd be happy to make the changes as a modification of django-hijack and offer up a pull request.

Please click 👍 if you'd like to see this feature implemented

django-hijack v3.0.0 django-hijack-admin v2.1.10

I'm using the Django admin integration app so I can hijack users from the admin interface.

When I release a user, Django reloads the last hijacked page instead of loading what I set in my settings:

HIJACK_LOGOUT_REDIRECT_URL = '/django-admin/auth/user/'

In fact, if I don't set HIJACK_LOGOUT_REDIRECT_URL, the default behavior (loading LOGIN_REDIRECT_URL) doesn't work neither.