appweb总结2-User Authentication

Appweb implements a powerful and flexible authentication framework that verifies username and password and verifies client capabilities using a role based authorization mechanism.

说白了就是：APPWEB支持通过配置文件设置可以对指定的网页进行权限控制，可惜这种方式会存在安全问题，所有建议使用TLS/SSL。

一、Authentication Schemes（方式）

Appweb provides several authentication protocol schemes.

a、Web Form Authentication:(推荐使用)
b、Basic Authentication：not recommend 
c、Digest Authentication: not recommend 
because Basic and Digest authentication standards employ weak ciphers, repeatedly send credentials over the wire and and are not sufficiently secure.

二、Configuring Authentication

The authentication scheme is selected and controlled by the AuthType appweb configuration directive. This directive may be used inside a Route, VirtualHost block, or default server configuration.
AuthType Define the type of authentication to use: Basic or Digest.
如：AuthType form example.com
AuthStore Define the authentication method: "config" or "system".
如：AuthStore config
    User julie 9d8873a123eb506e7f8e84d1f2a26916 administrator administrator 

    Role administrator manage

三、Form Authentication
1、定义：uses a web page for the user to enter their username and password. These values are then submitted to Appweb via a Http POST request. Appweb analyzes the username and password, and if authenticated, a login session is created and a cookie is returned to the users's browser. Subsequent requests that include the cookie will be automatically authenticated and served.

2、配置：
the AuthType directive may take additional arguments to manage the login sequence. The Form variant of AuthType may specify a login web page, a login service URL, a logout service URL, a destination web page once authenticated and a destination page once logged out.

The format is:
AuthType form realm Login-Page Login-Service Logout-Service Logged-In-Destination Logged-Out-Destination

This defines the URLs that are invoked during the login sequence and creates special request routes for these URLs. These routes will permit access to the login page and login service so they can be accessed by unauthenticated users. Each of these AuthType arguments is optional and may be specified as the empty string "" to omit. For example:

<Route ^/>
    AuthType form example.com /public/login.html /login /logout /index.html /public/login.html
</Route>

<Route ^/public/>
    Prefix /public
    Documents public
    AuthType none
</Route>

This example enables Form authentication for all requests and will redirect the client browser to /public/login.html where the user can enter their username and password. The login web page should submit the username and password to the login service bound to the /login URL. When logout is required, the client should submit a HTTP POST request to the logout service bound to the /logout URL. The last two fields in the AuthType directive are the destination URL to which the client's browser will be redirected once logged in and when logged out. The second /public route enables access to documents under the "public" directory without authentication.

3、登陆服务
The Login-Service is URL that is bound to an internal service to receive the username and password and authenticate the user. This service expects the username/password to be submitted via POST data using the input fields "username" and "password". You can supply your own login and logout service by specifying the empty string "" for the Login-Service in the AuthType directive. If using your own Login Service, you should call httpLogin to validate the user against the configured password store.

4、Web Frameworks
If you are using ESP, Ejscript, PHP or other web framework, you should not use the extended AuthType directive with URLs. This is because these web frameworks have integrated login facilities that are more natural to use within the web framework. The extended AuthType form directive is ideal for web sites using static web pages as it seamlessly manages the browser page transitions during login.

5、Require Directive
The Require directive controls access to the resources managed by the route. There are three possibilities to control access: require specific named users, require a secure protocol such as TLS/SSL to be used, and require that the authenticated user possess a set of specified abilities.

Require user username ...
Require ability name...
Require secure
When using Require ability, the abilities may be roles defined via the Role directive, abilities specified in Role definitions, or they may be simple words which represent a discrete ability that is explicitly specified with roles in the User directive.

The require secure directive specifies that the SSL/TLS protocol must be used for the request to permit access. The redirect "secure" directive may be used to seamlessly redirect the user's browser to use SSL for the same URL.

Note: These three require directive alternatives may be used in combination. However, multiple Require user or multiple Require ability directives are not supported. The last directive will take precedence.