Django

Code

Ticket #5612 (new)

Opened 3 years ago

Last modified 2 weeks ago

Signals for login / logout

Reported by: pterk Assigned to: SmileyChris
Milestone: Component: Core framework
Version: SVN Keywords:
Cc: pterk@datatailors.com, bthomas@ncircle.com, siddhartag@hotmail.com, egmanoj@gmail.com, mmitar@gmail.com Triage Stage: Design decision needed
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

A small patch that adds signals for login / logout events. The signal passes on the request. I use it to clean up session-data.

Attachments

login_logout_signals.diff (1.4 kB) - added by pterk on 09/26/07 16:08:09.
login_logout_signals-2.diff (1.4 kB) - added by pterk on 09/27/07 08:11:47.
Self contained (moved signals to contrib.auth.signals)
login_logout_signals_r10823.diff (1.6 kB) - added by JohnDoe on 05/20/09 13:54:09.
5612.diff (7.1 kB) - added by SmileyChris on 05/03/10 22:11:56.

Change History

09/26/07 16:08:09 changed by pterk

  • attachment login_logout_signals.diff added.

09/26/07 18:10:59 changed by anonymous

  • needs_better_patch set to 1.
  • needs_tests changed.
  • needs_docs changed.

I believe the contrib modules are supposed to be self-contained, so should the signal objects should probably be within contrib.auth rather than core.

09/27/07 08:11:47 changed by pterk

  • attachment login_logout_signals-2.diff added.

Self contained (moved signals to contrib.auth.signals)

09/28/07 08:39:46 changed by anonymous

  • cc set to pterk@datatailors.com.

11/30/07 17:17:55 changed by brosner

  • status changed from new to closed.
  • resolution set to wontfix.

Marking as wont fix. Signal dispatching is slow. This should be accomplished using the daily_cleanup.py found in django/bin. If that doesn't suit you then rewrite parts of django.contrib.auth or maybe through a custom auth backend. Please reopen with better use cases. I just don't see signals being a solution to really any use case for something like this.

12/01/07 03:15:28 changed by anonymous

Signals are slow, but login and logout events would occur so rarely that signal performance shouldn't be a consideration here.

12/02/07 14:27:38 changed by pterk

Another use case could be to log all login/outs in a single place (iso /admin/, /accounts/registration and possibly other locations or rewriting bits of django core). To alleviate the worries about speed, it could be made entirely optional and off by default.

12/02/07 14:36:46 changed by brosner

  • status changed from closed to reopened.
  • resolution deleted.
  • stage changed from Unreviewed to Design decision needed.

Alright, I am going to re-open this ticket to get some exposure by the core devs. There are a few use cases for this and having an optional on and off switch would be nice to alleviate any performance issues.

02/26/08 07:02:22 changed by PJCrosier

  • has_patch set to 1.

12/16/08 14:28:37 changed by bthomas

  • cc changed from pterk@datatailors.com to pterk@datatailors.com, bthomas@ncircle.com.

05/20/09 13:54:09 changed by JohnDoe

  • attachment login_logout_signals_r10823.diff added.

05/20/09 13:56:33 changed by JohnDoe

Updated patch to work with newer version, changed behavior to trigger login signal before updating last_login because i need to log time between logins.

05/23/09 07:02:35 changed by siddhi

  • cc changed from pterk@datatailors.com, bthomas@ncircle.com to pterk@datatailors.com, bthomas@ncircle.com, siddhartag@hotmail.com.

07/15/09 02:55:15 changed by anonymous

  • cc changed from pterk@datatailors.com, bthomas@ncircle.com, siddhartag@hotmail.com to pterk@datatailors.com, bthomas@ncircle.com, siddhartag@hotmail.com, egmanoj@gmail.com.

10/02/09 02:56:07 changed by imbaczek@gmail.com

another use case: demo users - profiles, passwords and other data needs to be reset on login/logout.

11/17/09 17:58:56 changed by coleifer

I'd love to see this one - we'd like to hook into the login process and are considering wrapping the default views. What's the status on this one?

05/03/10 22:10:54 changed by SmileyChris

  • owner changed from nobody to SmileyChris.
  • needs_better_patch deleted.
  • status changed from reopened to new.

New patch with docs & tests. Also moved the update for last_login to a signal which allows for it to be disconnected if someone wanted to.

05/03/10 22:11:56 changed by SmileyChris

  • attachment 5612.diff added.

05/03/10 22:12:58 changed by SmileyChris

  • summary changed from [patch] Signals for login / logout to Signals for login / logout.

06/17/10 19:19:10 changed by mitar

  • cc changed from pterk@datatailors.com, bthomas@ncircle.com, siddhartag@hotmail.com, egmanoj@gmail.com to pterk@datatailors.com, bthomas@ncircle.com, siddhartag@hotmail.com, egmanoj@gmail.com, mmitar@gmail.com.

Another use case: with signal you could add a message to the user informing her that she was successfully logged in or out and redirect her to the page she wanted to go in the first place and not to the default login page. It is a nice information to users that they know what is happening behind the scenes.

07/16/10 23:27:28 changed by drizzo4shizzo

I'd love to see this as in my app I'm currently wrapping the default login view to store login attempts. So preferably a hook for a successful login and another for a failed attempt.

I tried using a custom authentication back end to handle failed login attempts but those only get username/password - need the http request to dig out IP...

07/17/10 03:20:55 changed by SmileyChris

mitar: using signals doesn't just make that possible. In fact, it confuses the issue more: what if you have two conflicting responses from signal listeners?

drizzo4shizzo: that's an interesting idea - I don't think it's part of this primary ticket though so perhaps you should open a new ticket for that (and crosslink it to here)

07/17/10 13:31:08 changed by mitar

I do not understand why it would not be possible. I am quite happily using such views:

def login(request, *args, **kwargs):
  res = login_view(request, *args, **kwargs)
  if request.user.is_authenticated():
    signals.user_login.send(sender=login, request=request, user=request.user)
  return res
def logout(request, *args, **kwargs):
  user = request.user
  res = logout_view(request, *args, **kwargs)
  signals.user_logout.send(sender=logout_redirect, request=request, user=user)
  return res

07/17/10 13:32:59 changed by mitar

And then:

def user_login_message(request, user, **kwargs):
  messages.success(request, _("You have successfully logged in."), fail_silently=True)
user_login.connect(user_login_message)

def user_logout_message(request, user, **kwargs):
  messages.success(request, _("You have successfully logged out."), fail_silently=True)
user_logout.connect(user_logout_message)

07/17/10 14:39:31 changed by SmileyChris

Right, I get that adding a message would be a useful use of the signal.

It's was the "redirect her to the page she wanted to go in the first place and not the default login page" statement that I was referring to. It has nothing to do with signal listeners, which is what this ticket was about ;)

07/17/10 15:01:11 changed by mitar

Ah, yes. This is something else. I pass next parameter to login view so that user is redirected back to where it started the login process. So I do not use signals for redirecting. But once you do redirecting it is nice to tell user that login was successful, because otherwise just some small part of the page changes (like that username is written somewhere instead of "login" link). So messages are useful to tell the user this. And having signals then makes this really easy to do.


Add/Change #5612 (Signals for login / logout)




Change Properties
Action