1.1 --- a/docs/login-redirect.html Thu Jan 18 22:40:07 2007 +0000
1.2 +++ b/docs/login-redirect.html Thu Jan 18 22:40:48 2007 +0000
1.3 @@ -3,7 +3,6 @@
1.4
1.5 <title>LoginRedirect and Login Modules</title><meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
1.6 <link href="styles.css" rel="stylesheet" type="text/css" /></head>
1.7 -
1.8 <body>
1.9 <h1>LoginRedirect and Login Modules</h1>
1.10 <p>The <code>LoginRedirect</code> and <code>Login</code> modules
1.11 @@ -102,7 +101,7 @@
1.12 for this parameter, a simple page is presented to the user informing
1.13 them of the situation - it is recommended that a subclass of <code>LoginRedirectResource</code>
1.14 be employed should more informative pages be required.</dd>
1.15 -</dl>
1.16 +</dl><p>See the <a href="../apidocs/public/WebStack.Resources.LoginRedirect.LoginRedirectResource-class.html">API documentation</a> for the <code>LoginRedirectResource</code> class for more details.</p>
1.17 </div>
1.18 <h3>Redirection from/to the Application</h3>
1.19 <p>Some server/framework environments do not permit automatic
1.20 @@ -124,7 +123,11 @@
1.21 support the "single sign-on" aspects of this mechanism - mixing in such
1.22 classes with <code>LoginAuthenticator</code> may provide a solution to
1.23 this
1.24 -issue, however.</p>
1.25 +issue, however.</p><h2>Extending LoginRedirectResource</h2><p>Sometimes, using <code>LoginRedirectResource</code> directly is not appropriate in an application. For example, specifying the <code>app_url</code> and <code>login_url</code> as absolute URLs (so that <code>LoginRedirectResource</code> can
1.26 +redirect users into the application and over to the login screen) may
1.27 +seem like excessive detail which will need to be changed if the
1.28 +application is deployed even in a slightly different location. We might
1.29 +therefore wish to use a <code>PathSelector</code> resource (see <a href="attributes.html">"Transaction Attributes"</a> and <a href="selectors.html">"Selectors"</a>) to record the "root path" into an application and then to employ a login URL which is relative to the "root path".</p><p>To achieve this, <code>LoginRedirectResource</code> provides methods which can be overridden - <code>get_app_url</code> and <code>get_login_url</code> - and we might define a subclass of <code>LoginRedirectResource</code> as follows:</p><pre>class MyLoginRedirectResource(LoginRedirectResource):<br /><br /> "An example of customising LoginRedirectResource."<br /><br /> def get_login_url(self, trans):<br /><br /> "Use a different login URL, using 'trans' to find out what it might be."<br /><br /> # Find out what the PathSelector stored for the root of the application.<br /><br /> root_path = trans.get_attributes()["root"]<br /><br /> # Return the value of the login_url attribute appended to the root path.<br /><br /> return root_path + self.login_url</pre><p>Since <code>LoginRedirectResource</code> calls the <code>get_login_url</code> method when forming the URL to redirect to the login resource, by overriding the original method from the <code>LoginRedirectResource</code> class we can define different behaviour. Of course, to take advantage of this new behaviour, we must instantiate <code>MyLoginRedirectResource</code> instead of <code>LoginRedirectResource</code> when setting up the application.</p>
1.30 <h2>Deploying a Login Application</h2>
1.31 <p>In order for this authentication mechanism to function in its
1.32 entirety, a