You copied the Doc URL to your clipboard.

3.6. User and password lookup routine

Embedded systems in business environments usually have some configurable features that must be accessible to authorized users only. For example, not every employee should be able to change the IP address of a networked printer. HTTP supports this type of protection, using the UNIX-like user and password principle. Any HTML page can be flagged as part of a protected realm (a list of pages). Accessing pages in a realm requires the user to enter a valid user name and password at the browser. On an embedded system, the form to set the IP address would usually have this type of protection.

The following steps take place when a user first tries to access a protected form:

  1. The browser performs a standard HTTP GET request on the HTML page containing the form.

  2. The server realizes that the page is protected, and scans the HTTP header for an appropriate authorization field, which should contain an encoded user name and password.

  3. If this field is missing, which is usually the case on the first request, the server sends an HTTP error 402 (authorization failure) back to the browser.

  4. The browser displays a popup window to the user, asking for the name and password.

  5. The user enters this information, and the browser resends the HTTP GET request, this time with the authorization field.

  6. The server decodes and checks the name and password, and, if everything checks out, returns the protected HTML page.

To use this facility on the ARM Webserver, you must do two things:

  • flag the protected files, so the webserver knows when to require authorization

  • provide a routine to verify user names and passwords.

Files can be flagged as protected by adding either the -a or -5 option to their entry in the HTML Compiler input file. The routine to verify user names can perform any type of verification you desire. The syntax for the routine is shown in Example 3.2.

/* user authorization routine */

int
user_ok(char *user,	           /* decoded name of user from browser’s HTTP header*/
        char *password,       /* decoded password from browser */
        struct vfs_file *vfp) /* protected file’s entry */
{
....

The user name and password are passed in plain text because they have already been decoded. If organized realms are desired, the user code is responsible for initializing and maintaining them. The vfs_file structure has a name member to assist with this.

Note

The name of this routine must be user_ok(), and it must be provided if any files are flagged as protected.

For most embedded systems, a single user name and password for system privileges is stored in Non-Volatile Random Access Memory (NVRAM). Checking the passed parameters against these and returning nonzero (if access is permitted) or zero is usually sufficient.

Was this page helpful? Yes No