diff options
author | xue <> | 2006-03-23 13:25:09 +0000 |
---|---|---|
committer | xue <> | 2006-03-23 13:25:09 +0000 |
commit | 29d40192ed3dc0085b5e513ec071c81e03e95d3b (patch) | |
tree | 87e228522e19c93f7d9d9cda6109bc4d6421072d /demos/quickstart/protected/pages/Security/Auth.page | |
parent | 502ef5c173b2ca1220725d9814022102ea5dd749 (diff) |
Reorganized quickstart tutorial.
Diffstat (limited to 'demos/quickstart/protected/pages/Security/Auth.page')
-rw-r--r-- | demos/quickstart/protected/pages/Security/Auth.page | 92 |
1 files changed, 0 insertions, 92 deletions
diff --git a/demos/quickstart/protected/pages/Security/Auth.page b/demos/quickstart/protected/pages/Security/Auth.page deleted file mode 100644 index ec876f54..00000000 --- a/demos/quickstart/protected/pages/Security/Auth.page +++ /dev/null @@ -1,92 +0,0 @@ -<com:TContent ID="body" >
-
-<h1>Authentication and Authorization</h1>
-<p>
-Authentication is a process of verifying whether someone is who he claims he is. It usually involves a username and a password, but may include any other methods of demonstrating identity, such as a smart card, fingerprints, etc.
-</p>
-<p>
-Authorization is finding out if the person, once identified, is permitted to manipulate specific resources. This is usually determined by finding out if that person is of a particular role that has access to the resources.
-</p>
-
-<h2>How PRADO Auth Framework Works</h2>
-<p>
-PRADO provides an extensible authentication/authorization framework. As described in <a href="?page=Fundamentals.Applications">application lifecycles</a>, <tt>TApplication</tt> reserves several lifecycles for modules responsible for authentication and authorization. PRADO provides the <tt>TAuthManager</tt> module for such purposes. Developers can plug in their own auth modules easily. <tt>TAuthManager</tt> is designed to be used together with <tt>TUserManager</tt> module, which implements a read-only user database.
-</p>
-<p>
-When a page request occurs, <tt>TAuthManager</tt> will try to restore user information from session. If no user information is found, the user is considered as an anonymous or guest user. To facilitate user identity verification, <tt>TAuthManager</tt> provides two commonly used methods: <tt>login()</tt> and <tt>logout()</tt>. A user is logged in (verified) if his username and password entries match a record in the user database managed by <tt>TUserManager</tt>. A user is logged out if his user information is cleared from session and he needs to re-login if he makes new page requests.
-</p>
-<p>
-During <tt>Authorization</tt> application lifecycle, which occurs after <tt>Authentication</tt> lifecycle, <tt>TAuthManager</tt> will verify if the current user has access to the requested page according to a set of authorization rules. The authorization is role-based, i.e., a user has access to a page if 1) the page explicitly states that the user has access; 2) or the user is of a particular role that has access to the page. If the user does not have access to the page, <tt>TAuthManager</tt> will redirect user browser to the login page which is specified by <tt>LoginPage</tt> property.
-</p>
-
-<h2>Using PRADO Auth Framework</h2>
-<p>
-To enable PRADO auth framework, add the <tt>TAuthManager</tt> module and <tt>TUserManager</tt> module to <a href="?page=Configurations.AppConfig">application configuration</a>,
-</p>
-<com:TTextHighlighter Language="xml" CssClass="source">
-<service id="page" class="TPageService">
- <modules>
- <module id="auth" class="System.Security.TAuthManager"
- UserManager="users" LoginPage="UserLogin" />
- <module id="users" class="System.Security.TUserManager"
- PasswordMode="Clear">
- <user name="demo" password="demo" />
- <user name="admin" password="admin" />
- </module>
- </modules>
-</service>
-</com:TTextHighlighter>
-<p>
-In the above, the <tt>UserManager</tt> property of <tt>TAuthManager</tt> is set to the <tt>users</tt> module which is <tt>TUserManager</tt>. Developers may replace it with a different user management module that is derived from <tt>TUserManager</tt>.
-</p>
-<p>
-Authorization rules for pages are specified in <a href="?page=Configurations.PageConfig">page configurations</a> as follows,
-</p>
-<com:TTextHighlighter Language="xml" CssClass="source">
-<authorization>
- <allow pages="PageID1,PageID2"
- users="User1,User2"
- roles="Role1" />
- <deny pages="PageID1,PageID2"
- users="?"
- verb="post" />
-</authorization>
-</com:TTextHighlighter>
-<p>
-An authorization rule can be either an <tt>allow</tt> rule or a <tt>deny</tt> rule. Each rule consists of four optional properties:
-</p>
-<ul>
-<li><tt>pages</tt> - list of comma-separated page names that this rule applies to. If empty or not set, this rule will apply to all pages under the current directory and all its subdirectories recursively.</li>
-<li><tt>users</tt> - list of comma-separated user names that this rule applies to. A character * refers to all users including anonymous/guest user. And a character ? refers to anonymous/guest user.</li>
-<li><tt>roles</tt> - list of comma-separated user roles that this rule applies to.</li>
-<li><tt>verb</tt> - page access method that this rule applies to. It can be either <tt>get</tt> or <tt>post</tt>. If empty or not set, the rule applies to both methods.</li>
-</ul>
-
-<p>
-When a page request is being processed, a list of authorization rules may be available. However, only the <i>first effective</i> rule <i>matching</i> the current user will render the authorization result.
-</p>
-<ul>
-<li>Rules are ordered bottom-up, i.e., the rules contained in the configuration of current page folder go first. Rules in configurations of parent page folders go after.</li>
-<li>A rule is effective if the current page is in the listed pages of the rule AND the current user action (<tt>get</tt> or <tt>post</tt>) is in the listed actions.</li>
-<li>A rule matching occurs if the current user name is in the listed user names of an <i>effective</i> rule OR if the user's role is in the listed roles of that rule.</li>
-<li>If no rule matches, the user is authorized.</li>
-</ul>
-<p>
-In the above example, anonymous users will be denied from posting to <tt>PageID1</tt> and <tt>PageID2</tt>, while <tt>User1</tt> and <tt>User2</tt> and all users of role <tt>Role1</tt> can access the two pages (in both <tt>get</tt> and <tt>post</tt> methods).
-</p>
-
-<h2>Using <tt>TUserManager</tt></h2>
-<p>
-As aforementioned, <tt>TUserManager</tt> implements a read-only user database. The user information are specified in either application configuration or an external XML file.
-</p>
-<p>
-We have seen in the above example that two users are specified in the application configuration. Complete syntax of specifying the user and role information is as follows,
-</p>
-<com:TTextHighlighter Language="xml" CssClass="source">
-<user name="demo" password="demo" roles="demo,admin" />
-<role name="admin" users="demo,demo2" />
-</com:TTextHighlighter>
-<p>
-where the <tt>roles</tt> attribute in <tt>user</tt> element is optional. User roles can be specified in either the <tt>user</tt> element or in a separate <tt>role</tt> element.
-</p>
-</com:TContent>
\ No newline at end of file |