| paulb@654 | 1 | <?xml version="1.0" encoding="iso-8859-1"?> |
| paulb@360 | 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| paulb@360 | 3 | <html xmlns="http://www.w3.org/1999/xhtml"> |
| paulb@360 | 4 | <head> |
| paulb@360 | 5 | <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type" /> |
| paulb@360 | 6 | <title>Users and Authentication</title> |
| paulb@360 | 7 | <link href="styles.css" rel="stylesheet" type="text/css" /> |
| paulb@360 | 8 | </head> |
| paulb@360 | 9 | <body> |
| paulb@360 | 10 | <h1>Users and Authentication</h1> |
| paulb@360 | 11 | <p>One way of discovering the identity of the user sending a request |
| paulb@654 | 12 | into your application is to test the identity using methods on the |
| paulb@654 | 13 | transaction object. Before this can be made to work, you must set |
| paulb@360 | 14 | up authentication for your application, as described in <a |
| paulb@360 | 15 | href="securing.html">"Securing a WebStack Application"</a>. Once |
| paulb@360 | 16 | authentication is working, every request that arrives in the |
| paulb@360 | 17 | application will have the identity of the user attached automatically.</p> |
| paulb@360 | 18 | <h2>Uses of User Identity</h2> |
| paulb@360 | 19 | <p>Having access to a user's identity can be useful in making decisions |
| paulb@360 | 20 | about which operations that user is able to perform within your |
| paulb@360 | 21 | application. Moreover, the user identity provided by authentication |
| paulb@360 | 22 | mechanisms can tell you more about who that user is, as opposed to |
| paulb@360 | 23 | typical session information which, on its own, can only really confirm |
| paulb@360 | 24 | that the user in question has visited the application before.</p> |
| paulb@360 | 25 | <div class="WebStack"> |
| paulb@360 | 26 | <h3>WebStack API - User Identity</h3> |
| paulb@360 | 27 | <p>Transaction objects have the following methods for inspecting and |
| paulb@360 | 28 | redefining the identity of users:</p> |
| paulb@360 | 29 | <dl> |
| paulb@360 | 30 | <dt><code>get_user</code></dt> |
| paulb@360 | 31 | <dd>This gets the name of the user attempting to access the |
| paulb@360 | 32 | application.</dd> |
| paulb@360 | 33 | <dt><code>set_user</code></dt> |
| paulb@360 | 34 | <dd>This sets the name of the user, thus affecting subsequent calls |
| paulb@360 | 35 | to <code>get_user</code>, allowing certain parts of an application to |
| paulb@360 | 36 | view users according to other criteria than their basic username - for |
| paulb@360 | 37 | example, one might use <code>set_user</code> to redefine each user's |
| paulb@360 | 38 | identity in terms of the role that user may have in an application.</dd> |
| paulb@360 | 39 | </dl> |
| paulb@360 | 40 | </div> |
| paulb@360 | 41 | </body> |
| paulb@360 | 42 | </html> |
