Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #754 (closed enhancement: migrated)

Opened 12 years ago

Last modified 7 years ago

Event API

Reported by: Claudio Martinez Owned by:
Priority: normal Milestone: 1.5
Component: TurboGears Version: 1.1
Severity: normal Keywords:


It would be nice to have the posibility to add functions to certain identity events.

One example

import identity

def login_succesful(user):

# setup some session data


Would help clear a lot of redundant code from controllers.


events.diff Download (5.9 KB) - added by Claudio Martinez <martinezc@…> 12 years ago.
events.2.diff Download (6.1 KB) - added by Claudio Martinez <martinezc@…> 12 years ago.
There was a file missing on that last patch, sorry

Change History

comment:1 Changed 12 years ago by jeff

  • Priority changed from normal to low
  • Version 0.9a4 deleted
  • Milestone 0.9 deleted

This would be ideal if the event system were TurboGears wide. In fact, that's the only way I would recommend doing it.

comment:2 Changed 12 years ago by Claudio Martinez <martinezc@…>

Attached is a patch that adds some event handling to identity using a generic event system. It's very, very simple, and other parts of turbogears can add events too.

I'm using this right now and works for me. I want to share this with other people that ran into the same limitations I did. There's no way of doing this without modding identity.


import turbogears

def _on_logout(d):
    # clear session data
def _on_success(d):
    # setup some session data

def _on_failure(d):
    # audit

def _before_validation(d):
    # mangle username or password if you like

def _after_validation(d):
    # audit

d has the keys 'user_name', 'pw', 'visit_key' and, depending if the login was succesful, 'identity'.

In the patch I moved some stuff out of a try: except: block because it was only there to catch some KeyError?'s from some pops and it was executing the validation method inside it, complicating debugging. Someone may want to open a separate ticket for this, anyone developing a new identity provider will thank you :)

Changed 12 years ago by Claudio Martinez <martinezc@…>

Changed 12 years ago by Claudio Martinez <martinezc@…>

There was a file missing on that last patch, sorry

comment:3 Changed 11 years ago by roger.demetrescu

  • Summary changed from Identity events to [PATCH] Identity events

making this ticket visible in "Pending Patches" report

comment:4 Changed 11 years ago by jorge.vargas

  • Milestone set to 1.1

I believe this should be implemented as a TG feature not just identity

comment:5 Changed 11 years ago by claudio.martinez

I've been using the provided patch for quite a while now, it's stable. It's very simple, just based on dictionaries and lists so it's lacking some features.

CherryPy? 3 added a nice mechanism  check here on the hooks section, maybe we can use it if TG 1.1 is planned to use CP3.

comment:6 Changed 11 years ago by alberto

  • Status changed from new to assigned
  • Component changed from Identity to TurboGears
  • Summary changed from [PATCH] Identity events to Event API
  • Priority changed from low to normal
  • Milestone changed from 1.1 to 2.0
  • Owner changed from anonymous to alberto

Currently 1.0 is in a feature freeze so this will have to be filed under 2.0 (I think we're jumping there from 1.0 directly, aren't we?).

2.0 will most proably have all the identity/visit code rewritten separating authentication from authorization on differerent components. There are various authentication middleware components we could use (AuthKit?, wsgiauth, ...). This will probably invalidate the patches.

An event API could be integrated too, as Jorge said, better have it generic enough so we can register/un-register any kind of event listener and create signals. There's probably some library out there at the cheeseshop we could integrate somehow. The first problem I see with the proposed dict implementation in the patch is that it's not thread-safe and doesn't seem to have an interface for un-registering events :(

Fortunately 1.0b2 is quite stable right now so I think I can safely say that you can run a patched TG installation with no fear of major tweaking on the next 1.0 releases.

I'll change the summary to "Event API" and change the milestone to keep this ticket as a reminder.


comment:7 Changed 11 years ago by alberto

  • Status changed from assigned to new
  • Owner alberto deleted

comment:8 Changed 10 years ago by mramm

  • Milestone changed from 2.0 to 1.1

Not sure if this should be implemented, but if it is it should go in the 1.1 line since 2.0 is radically different.

Perhaps it make sense to think about some event system for Pylons/Turbogears? 2. But I think it would need to be implemented at the Pylons level. If that's a desired outcome, please create a new ticket in for 2.0 or create a ticket in pylons trac.

comment:9 Changed 9 years ago by faide

  • Milestone changed from 1.1 to 1.1.1

thread safe event system is a must have... we should find an event lib on the cheeseshop and make sure we'll be able to use the same in tg2.

comment:10 Changed 9 years ago by faide

  • Milestone changed from 1.6 to 1.5

comment:11 Changed 7 years ago by chrisz

  • Version set to 1.1

comment:12 Changed 7 years ago by chrisz

  • Status changed from new to closed
  • Resolution set to migrated
Note: See TracTickets for help on using tickets.