iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add some initial details for the authentication handling.

This commit is contained in:
Greg Stein 2001-08-21 08:16:35 +00:00
parent 5331ad949f
commit 05a939622a
1 changed files with 88 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

98
pep-0268.txt
View File

@ -13,7 +13,7 @@ Post-History:
Abstract
This PEP discusses new modules and extended functionality for
Python's HTTP support. Notably, the addition of authenticated
Python's HTTP support. Notably, the addition of authenticated
requests, proxy support, authenticated proxy usage, and WebDAV [1]
capabilities.
@ -21,46 +21,124 @@ Abstract
Rationale
Python has been quite popular as a result of its "batteries
included" positioning. One of the most heavily used protocols,
HTTP, has been included with Python for years (httplib). However,
included" positioning. One of the most heavily used protocols,
HTTP [2], has been included with Python for years (httplib). However,
this support has not kept up with the full needs and requirements
of many HTTP-based applications and systems. In addition, new
of many HTTP-based applications and systems. In addition, new
protocols based on HTTP, such as WebDAV and XML-RPC, are becoming
useful and are seeing increasing usage. Supplying this
useful and are seeing increasing usage. Supplying this
functionality meets Python's "batteries included" role and also
keeps Python at the leading edge of new technologies.
While authentication and proxy support are two very notable
features missing from Python's core HTTP processing, they are
minimally handled as part of Python's URL handling (urllib and
urllib2). However, applications that need fine-grained or
urllib2). However, applications that need fine-grained or
sophisticated HTTP handling cannot make use of the features while
they reside in urllib. Refactoring these features into a location
they reside in urllib. Refactoring these features into a location
where they can be directly associated with an HTTP connection will
improve their utility for both urllib and for sophisticated
applications.
The motivation for this PEP was from several people requesting
these features directly, and from a number of feature requests on
SourceForge. Since the exact form of the modules to be provided
SourceForge. Since the exact form of the modules to be provided
and the classes/architecture used could be subject to debate, this
PEP was created to provide a focal point for those discussions.
Specification
more info here...
Two modules will be added to the standard library: 'httpx' (HTTP
extended functionality), and 'davlib' (WebDAV library).
[ suggestions for module names are welcome; davlib has some
precedence, but something like 'webdav' might be desirable ]
HTTP Authentication
The httpx module will provide a mixin for performing HTTP
authentication (for both proxy and origin server
authentication). This mixin (httpx.HandleAuthentication) can be
combined with the HTTPConnection or the HTTPSConnection classes
(the mixin may possibly work with the HTTP and HTTPS compatibility
classes, but that is not a requirement).
The mixin will delegate the authentication process to one or more
"authenticator" objects, allowing multiple connections to share
authenticators. The use of a separate object allows for a long
term connection to an authentication system (e.g. LDAP). An
authenticator for the Basic mechanism [3] will be provided. Digest
would be great, but we need to find some code for it (or a
motivated developer). User-supplied authenticator subclasses can
be registered and used by the connections.
A "credentials" object is also associated with the mixin, and
stores the credentials (e.g. username and password) needed by the
authenticators. Subclasses of the credentials object can be
created to hold additional information (e.g. NT domain).
The mixin overrides the getresponse() method to detect 401
(Unauthorized) and 407 (Proxy Authentication Required)
responses. When this is found, the response object, the
connection, and the credentials are passed to the authenticator
corresponding with the authentication scheme specified in the
response (multiple authenticators are tried in decreasing order of
security if multiple schemes are in the response). Each
authenticator can examine the response headers and decide whether
and how to resend the request with the correct authentication
headers.
Resending a request, with the appropriate credentials, is one of
the more difficult portions of the authentication system. The
difficulty arises in recording what was sent originally: the
request line, the headers, and the body. By overriding putrequest,
putheader, and endheaders, we can capture all but the body. Once
the endheaders method is called, then we capture all calls to
send() (until the next putrequest method call) to hold the body
content. The mixin will have a configurable limit for the amount
of data to hold in this fashion (e.g. only hold up to 100k of body
content). Assuming that the entire body has been stored, then we
can resend the request with the appropriate authentication
information.
[ what to do when the body is too big: raise an error? special
return value? ... ]
[ need more info here about storing realms/headers in the
credentials object (keyed by host, port) ... resending those
automatically when making requests ... persisting the credentials
object to have the info next time ... ]
[ two sets of credentials: one for proxy, one for origin ... ]
Proxy Handling
... info about proxy handling ... note that proxy auth is handled
above ...
WebDAV Features
... info about the dav module ...
Reference Implementation
reference imp will probably go into /nondist/sandbox/...
reference impl will probably go into /nondist/sandbox/ until
accepted into the main Lib directory ...
References
[1] http://www.webdav.org/
[2] http://asg.web.cmu.edu/rfc/rfc2616.html
[3] http://asg.web.cmu.edu/rfc/rfc2617.html
Copyright