# Module: Auth

## About this module

The Auth module administrates all persistent FTP and HTTP authentication information, and the general UI actions (via WindowCommander) required to ask the user about the username and password

Supported protocols:

- HTTP 1.1
- FTP

## Interface overview and API documentation

API documentation generated by Doxygen contains all necessary information for the external APIs.

## Implementation description

API documentation generated by Doxygen contains information about the internal organization of the module.

### The URL_Rep class

### Authentication_Manager

The URL manager maintains the following

- All currently entered HTTP and FTP passwords
- A list of all th epending requests for passwords on a HTTP and FTP password
- A number of UI actions related to the above list
- The module also contain a number of authentication related fucntions defined in classes primarily maintained by the URL module.

### Basic Authentication element

Contains the credentials for FTP and normal unprotected HTTP credentials (known as Basic Authentication)

### Digest Authentication

Contains the state of the credentials for HTTP authentication using Digest Authentication

### Footprint

The module is moderately.

Various features can be enabled or disabled, either thorugh feature defines or specific defines, one example is the Diegest Authentication functionality.

Due to the requirements from various modules (including the url module) and platforms it is very difficult to reduce the footprint

### Dynamic memory use and OOM handling

OOM policies

  Most of internal module functions handles OOM locally, and signals an OOM by raising the OOM signal in the memory manager, and aborts the current action. If appropriate a message is posted to the document.

  However, much of the public API is now LEAVE based, and in those cases the caller must TRAP errors and handle them. Some internal functions will also LEAVE, but these are TRAPed internally

Who handles OOM?
  In the case of LEAVE functions the caller must TRAP the errors, and handle the OOM situations. In the case of the internal functions these usually aborts their operation with an error message, and a raised status flag, which must be handled either by the caller, or the document.
Flow

  Much of the module is message callback based, and these functions are not able to report OOM situations directly to the documents or UI. In these cases the current operation will be terminated, and errormessages sent.

  Much of the external API is based on direct calls, but some classes do use virtual fucntions. In many cases these are LEAVE bases, and callers must TRAP them and handle them appropriately.

Heap memory usage

  Memory is allocated for each authentication credential stored. This usually amounts to a few hundred bytes per credentials, although Digest may require more.

Stack memory usage

  Usually large objects are allocated. In some cases sizeable objects are placed on the stack but only for shorter periods.

  In most cases stack consumption should be less than 300 bytes.

Static memory usage

  Some const arrays are maintained, and some persistent data is kept in the URL Manager.

Caching and freeing memory

  Credentials are cached in the ServerName object, and can be deleted by deleting sensitive data through the URL_API

Freeing memory on exit

  Memory is freed by the URL Manager shutdown.

Temp buffers

  The module uses the memory Manager's shared temporary buffers for internal operations. As these functions are always called under controlled conditions there is no danger of collision.

Memory tuning

  At present there are no opportunities to tune memory use.

Tests

  Selftests, but they do not check memory usage.

Coverage

  Selftests, ordinary surfing, reading email.

Design choices

  Each specific method is implemented as a separate class

Improvements

  Currently there are no plans for improvement