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 12 and Version 13 of AuthFramework


Ignore:
Timestamp:
Aug 22, 2008, 10:19:12 PM (13 years ago)
Author:
cmlenz
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AuthFramework

    v12 v13  
    1 = Framework for Authentication and Authorization =
     1= Authentication and Authorization =
    22
    3 This page describes an [source:branches/experimental/auth-framework experimental branch] that adds a simple generic auth framework to Diva.
     3Diva includes a simple but flexible subsystem for authentication and authorization.
    44
    5 The main goals of this framework are:
     5The main goals of this subsystem are:
    66
    77 * Enable relatively easy switching between HTTP authentication (such as `Basic` or `Digest` authentication performed by the web server) and form-based authentication.
     
    1111 * No restriction to a specific method of controlling access to resources (such as ACLs). Applications can use whatever access control granularity they need.
    1212 * Storage-independent generation and verification of authentication cookies for form-based login.
    13 
    14 Possible/peripheral goals:
    15 
    1613 * Utility functions for generating and verifying encrypted passwords.
    1714 * WSGI middleware for using HTTP authentication, primarily in the context of the DevelopmentServer
    1815
    19 All of the above is implemented on the branch at this point.
    20 
    21 Non-goals include:
    22 
    23  * Built-in processes and UI for user registration, activation, password resetting, and other high-level features.
     16The subsystem does not provide built-in processes and UI for user registration, activation, password resetting, and other high-level features.
    2417
    2518=== Open Issues ===
     
    3023 * The password encryption utilities are a bit on the silly side. They should either be really useful or get nixed.
    3124
    32 == High-Level Architecture Stuff ==
     25== Basic Architecture ==
    3326
    34 === Application Mixin Approach ===
    35 
    36 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.
     27The `diva.auth` module provides an `AuthMixIn` class that auth-enabled applications are supposed to subclass. It adds a couple of method stubs to `Application` subclasses, and contributes a [wiki:RequestFilters request filter] that performs authentication.
    3728
    3829A concrete application would inherit from `AuthMixIn` in addition to being derived from [wiki:ApplicationObject Application], and would probably want to implement two methods for handling the domain-specific details of identifying users and controlling their access to certain actions and/or resources. For example:
     
    5142        return True
    5243}}}
    53 
    54 === Filters Refactoring ===
    55 
    56 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:
    57 
    58 {{{
    59 #!python
    60 @filters.register('form-processing', requires=['templating', 'localization'])
    61 def form_filter(request, response, chain):
    62     ...
    63 }}}
    64 
    65 The ordering of request filters is then inferred from this dependency information.
    6644
    6745== Authentication Methods ==