Changes between Version 2 and Version 3 of AuthFramework

Timestamp:

Aug 6, 2008, 12:48:07 PM (16 years ago)

Author:

cmlenz

Comment:

Note about refactored filter registration

AuthFramework

@@ -13 +13 @@
 Possible/peripheral goals:
 
+ * Utility functions for generating and verifying encrypted passwords.
  * WSGI middleware for using `Basic` and `Digest` authentication, primarily in the context of the DevelopmentServer
 
@@ -21 +22 @@
 == Application Mixin Approach ==
 
-The current branch defines an `AuthMixIn` class that auth-enabled applications are supposed to subclass. It adds a couple of method stubs to the `Application` class, and contributes a [wiki:RequestFilters request filter] (the details of adding the request filter are rather problematic right now, I'm thinking about various ways for having them order semi-automatically by declaring dependencies).
+The current branch defines an `AuthMixIn` class that auth-enabled applications are supposed to subclass. It adds a couple of method stubs to the `Application` class, and contributes a [wiki:RequestFilters request filter] that performs authentication.
 
+== Filters Refactoring ==
+
+Due to the way application mix-in classes can contribute filters, ordering request filters explicitly becomes too painful. The branch enhances the way request filters are defined by allowing them to declare the abstract service they provide (such as "localization" or "error-handling"), and also declare what services they rely on to do their job. For example:
+
+{{{
+#!python
+@filters.register('form-processing', requires=['templating', 'localization'])
+def form_filter(request, response, chain):
+    ...
+}}}
+
+The ordering of request filters is then inferred from this dependency information.