-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hijack session variables are not available until after hijack is fully completed #110
Comments
@alex-kaufman Thank you for your feedback. I currently do not see a way to solve this issue with an extra session variable. Django creates a new session when However, django-hijack has its own signals (http://django-hijack.readthedocs.org/en/latest/#signals). Perhaps you could catch |
@alex-kaufman Does df7a3f9 fixes your issue? tl;dr the If it does, please remember to close this issue! Thanks. |
Unfortunately it does not. The |
Signals cannot be disconnected in the meaning you seem to understand. What can be disconnected are signal handlers, that are functions called when a specific signal AFAICT, what we need is a custom django-hijack authentication backend that would be applied to the hijacked user – nothing complicated, just a documented class. That way, you can check in your signal handler what backend the user was logged in with, as it is storred in I'll try to test that solution in the coming days. |
Is there a fix for this. I have handlers listening to user_logged_in which is being fired whenever someone hijacks an account. I do not want my handler to account for hijacked accounts. Is there a way to avoid this? |
@alex-kaufman just wanted to double check if there was a solution for figuring out if a user session is hijacked for a signal receiver for user_logged_in |
Could we close this? |
@zopieux @philippeowagner No. I think this issue can't be closed. The commit df7a3f9 (@zopieux said) will disconnect But the problem is that it will only disconnect the Currently I avoid using the |
I feel dirty to suggest it, but until this is properly fixed, a possible workaround would be to test the
|
Why is there still no clear solution for this? |
Most likely your request is no longer relevant after the release of version 3.0 (currently in pre-release status). If it is not, please reopen your ticket. |
Hello, I think this has not been solved with 3.0. If I do:
here is_hijacked_user is The "dirty" trick suggested here still works, but it would be great if this was not necessary |
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.The text was updated successfully, but these errors were encountered: