1.1 --- a/docs/authenticators.html Sat Apr 30 00:22:03 2005 +0000
1.2 +++ b/docs/authenticators.html Sat Apr 30 20:31:51 2005 +0000
1.3 @@ -1,101 +1,69 @@
1.4 -<?xml version="1.0" encoding="iso-8859-1"?>
1.5 -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
1.6 - "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
1.7 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
1.8 <html xmlns="http://www.w3.org/1999/xhtml">
1.9 <head>
1.10 <title>Application-Wide Authenticators</title>
1.11 - <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
1.12 + <meta name="generator"
1.13 + content="amaya 8.1a, see http://www.w3.org/Amaya/" />
1.14 <link href="styles.css" rel="stylesheet" type="text/css" />
1.15 </head>
1.16 -
1.17 <body>
1.18 <h1>Application-Wide Authenticators</h1>
1.19 -
1.20 <p>Authenticators are special classes which can, in conjunction with
1.21 -mechanisms in the server environment, judge whether a user of an application
1.22 +mechanisms in the server environment, judge whether a user of an
1.23 +application
1.24 is recognised or not. The process of using authenticators is as follows:</p>
1.25 <ol>
1.26 - <li>Set up authentication in the server environment or framework in which
1.27 - the application is to be deployed.</li>
1.28 + <li>Set up authentication in the server environment or framework in
1.29 +which the application is to be deployed.</li>
1.30 <li>Introduce an authenticator class in the application.</li>
1.31 </ol>
1.32 -
1.33 <h2>Setting Up Authentication</h2>
1.34 -
1.35 -<p>The exact details of configuring authentication mechanisms in each server
1.36 -environment may vary substantially. For example, Apache environments require
1.37 -that <code>Auth</code> directives be specified in the Apache configuration
1.38 -files (see <code>docs/ModPython/NOTES.txt</code>); in Zope environments,
1.39 -protected folders can be defined to hold the application when deployed (see
1.40 +<p>The exact details of configuring authentication mechanisms in each
1.41 +server
1.42 +environment may vary substantially. For example, Apache environments
1.43 +require
1.44 +that <code>Auth</code> directives be specified in the Apache
1.45 +configuration
1.46 +files (see <code>docs/ModPython/NOTES.txt</code>); in Zope
1.47 +environments,
1.48 +protected folders can be defined to hold the application when deployed
1.49 +(see
1.50 <code>docs/Zope/NOTES.txt</code>).</p>
1.51 -
1.52 <h2>Defining an Authenticator</h2>
1.53 -
1.54 -<p>An authenticator must be defined within your application in order to make
1.55 +<p>An authenticator must be defined within your application in order to
1.56 +make
1.57 decisions about users who have presented their credentials; this
1.58 -authenticator will respond with a decision when prompted by the server or
1.59 -underlying framework, either allowing or denying access for the user whose
1.60 +authenticator will respond with a decision when prompted by the server
1.61 +or
1.62 +underlying framework, either allowing or denying access for the user
1.63 +whose
1.64 identity has been presented to the server/framework.</p>
1.65 -
1.66 <p>The code for an authenticator usually looks like this:</p>
1.67 -<pre>class MyAuthenticator:
1.68 -
1.69 - "This is an authenticator - something which decides whether a user is known to the application."
1.70 -
1.71 - def authenticate(self, trans):
1.72 - user = trans.get_user()
1.73 - [Make a decision about the validity of the user.]
1.74 - [Return a true value if the user is allowed to access the application.]
1.75 - [Return a false value if the user is not recognised or allowed to access the application.]
1.76 -
1.77 - def get_auth_type(self):
1.78 - "This method returns 'Basic' in most deployments."
1.79 - return "Basic"
1.80 -
1.81 - def get_realm(self):
1.82 - "This method returns something to distinguish this authentication mechanism from others."
1.83 - return "MyRealm"</pre>
1.84 -
1.85 -<p>In this mechanism, authenticators rely on authentication information from
1.86 -the server/framework and have a "global" effect on access to the application.
1.87 -However, it is always possible to test the user identity later on and to
1.88 -change the way an application behaves accordingly.</p>
1.89 -
1.90 -<div class="WebStack">
1.91 -<h3>WebStack API - User Identity</h3>
1.92 -
1.93 -<p>Transaction objects have the following methods for inspecting and
1.94 -redefining the identity of users:</p>
1.95 -<dl>
1.96 - <dt><code>get_user</code></dt>
1.97 - <dd>This gets the name of the user attempting to access the
1.98 - application.</dd>
1.99 - <dt><code>set_user</code></dt>
1.100 - <dd>This sets the name of the user, thus affecting subsequent calls to
1.101 - <code>get_user</code>, allowing certain parts of an application to view
1.102 - users according to other criteria than their basic username - for
1.103 - example, one might use <code>set_user</code> to redefine each user's
1.104 - identity in terms of the role that user may have in an application.</dd>
1.105 -</dl>
1.106 -</div>
1.107 -
1.108 +<pre>class MyAuthenticator:<br /><br /> "This is an authenticator - something which decides whether a user is known to the application."<br /><br /> def authenticate(self, trans):<br /> user = trans.get_user()<br /> [Make a decision about the validity of the user.]<br /> [Return a true value if the user is allowed to access the application.]<br /> [Return a false value if the user is not recognised or allowed to access the application.]<br /><br /> def get_auth_type(self):<br /> "This method returns 'Basic' in most deployments."<br /> return "Basic"<br /><br /> def get_realm(self):<br /> "This method returns something to distinguish this authentication mechanism from others."<br /> return "MyRealm"</pre>
1.109 +<p>In this mechanism, authenticators rely on authentication information
1.110 +from
1.111 +the server environment and have a "global" effect on access to the
1.112 +application.
1.113 +However, it is always possible to test the user identity later on and
1.114 +to
1.115 +change the way an application behaves accordingly - see <a
1.116 + href="users.html">"Users and Authentication"</a> for more information.</p>
1.117 <h2>Introducing an Authenticator</h2>
1.118 -
1.119 <p>Authenticator objects are created in the adapter code - see <a
1.120 -href="writing-adapters.html">"Writing Adapters"</a> for more information.</p>
1.121 -
1.122 + href="writing-adapters.html">"Writing Adapters"</a> for more
1.123 +information.</p>
1.124 <h2>Anonymous Access</h2>
1.125 -
1.126 -<p>With application-wide authenticators, anonymous access to resources and
1.127 -applications can be difficult to permit alongside access by specific users,
1.128 +<p>With application-wide authenticators, anonymous access to resources
1.129 +and
1.130 +applications can be difficult to permit alongside access by specific
1.131 +users,
1.132 mostly because servers and frameworks which employ HTTP authentication
1.133 schemes do so globally for a given application.</p>
1.134 -
1.135 <h2>Logout Functions</h2>
1.136 -
1.137 <p>With application-wide authenticators, a logout function may not be
1.138 available if the server/framework has been configured to use HTTP
1.139 -authentication schemes, mainly because no logout mechanism generally exists
1.140 +authentication schemes, mainly because no logout mechanism generally
1.141 +exists
1.142 for such schemes.</p>
1.143 </body>
1.144 </html>