Open mmulich opened 11 years ago
Great idea. I wouldn't subclass from NewRequest though. Is there a reason you did that? Events can be any object
.
I used NewRequest because it was an easy and document way to get the request in the event object without creating/recreating an event class, but an easy enough thing to change.
Sounds like you're in favor of the feature. Anything you have concerns about? If not, I'll put it together for the various provider classes and submit a pull request.
The feature is good but I think instead of separate subclasses for each provider I will just use a subscriber predicate based on the name of the provider. I've been pondering it as a better way of doing the authentication subclasses as well. I'm thinking something like:
@subscriber('velruse.BeforeLogin', provider_name='google')
def google_login_attempt(event):
# ...
I'm not sure what to call the PendingLogin
event, emitted after the redirect. That one may not be useful?
I'd like to add (feature request) before and after login view events (hook points).
Events on login are useful when using velruse as a plugin or possibly for extending the application. It allows the plugin user to modify/capture information before or after the login view is called; and this is important because there is no way to modify the login view without subclassing the provider. For example, after the login view is hit, one could capture the referrer location so that they could send the authenticated user back to where they came from.
An example implementation can be found at: https://github.com/pumazi/velruse/commit/7b520855f90e273e04cfcf864ffad0d0ac582d1c