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

Changes between Version 2 and Version 3 of AuthFramework


Ignore:
Timestamp:
Aug 6, 2008, 12:48:07 PM (13 years ago)
Author:
cmlenz
Comment:

Note about refactored filter registration

Legend:

Unmodified
Added
Removed
Modified
  • AuthFramework

    v2 v3  
    1313Possible/peripheral goals:
    1414
     15 * Utility functions for generating and verifying encrypted passwords.
    1516 * WSGI middleware for using `Basic` and `Digest` authentication, primarily in the context of the DevelopmentServer
    1617
     
    2122== Application Mixin Approach ==
    2223
    23 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).
     24The 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.
    2425
     26== Filters Refactoring ==
     27
     28Due 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:
     29
     30{{{
     31#!python
     32@filters.register('form-processing', requires=['templating', 'localization'])
     33def form_filter(request, response, chain):
     34    ...
     35}}}
     36
     37The ordering of request filters is then inferred from this dependency information.