[Libaps-general] Verification of named objects / components

[Jeff B. <kl...@ma...>]

From: "Jeff Brown" <jef...@co...>
Subject: Verification of named objects / components
Date: Monday, February 14, 2000 1:08 pm

Idea:
=====

Perform additional verifications of all named object / components which are
to be handled by APS.  For example, check string length for maximum size and
contents for invalid characters.

Proposal:
=========

Create a set of standard functions to be used in performing validation of
names and parameters on a semi-automatic basis.  Such functions would use a
constant description of the type of tests to be performed and would
adjust/modify any names as required by the implementation.  The description
may be either explicit, as in a table, or implicit, by the code structure
itself, or a mixture of both.

Explicit description:
Aps_Result verifyName(const StringCharacteristics *table, const char
*inString, char *outString) {
    <code uses the table to perform a series of checks then copies the input
parameter to the provided buffer>
    <returns: APS_NAME_TOO_LONG (error), APS_NAME_TRUNCATED (warning),
APS_NAME_INVALID_CONTENTS (error), APS_NAME_TRANSLATED (warning),
APS_NAME_REJECTED (generic error), etc...
}

Implicit description:
Aps_Result LprPrinterVerifyName(const char *inString, char *outString)
{
    <code performs checks directly and knows the special layout required by
this subsystem>
    <returns as above>
}

Mixture:
Aps_Result LprPrinterVerifyName(const char *inString, char *outString)
{
    <for routine checks; code uses generic functions with an explicit
description of what is being tested>
    <for special checks; code performs special verifications knowing the
layout required by this subsystem>
    <returns as above>

Affected areas:
===============

Any subsystems which must deal with input from the application (directly or
indirectly).
eg. Perform checks for validity of printer names
  - APS may admit names with spaces and of a certain length
  - Lpr does not admit names containing control characters, spaces, and may
limit name length due to constraints imposed by underlying filesystem or
server.  (eg. Lpr printer names should not exceed 30 or so characters
because some daemon and client implementations use small fixed length
buffers for communication purposes)
  - Direct consequence: if spaces, control chars or ':', '\', etc... are
admitted, LprAddPrinter will gladly insert an invalid entry into your
printcap file for you.  LprRemovePrinter will not be able to remove the new
entry because it will not know of its existence.

eg. Check job names for control characters
  - Lpr will get confused if presented with a \n in any name or title

eg. Translate document infomation
  - docTitle is presented to Lpr using the "T" tag in its control files.
Again '\n' will confuse Lpr but we do not wish to fail in this case.  It
would be preferable to transparently modify/encode the provided data
instead.

eg. Testing filename/pathname length
  - APS deals with filenames in many areas using fixed-length buffers.
While one could assume filenames will never exceed MAX_FILENAME_LENGTH
(sp?), the code would be somewhat cleaner if this check were done
explicitely.  At the same time, testing for invalid characters in filenames
may save APS some backing out if file-open fails.

eg. Asking the filesystem what it can do
  - Some filesystems are not case-sensitive or have different restrictions
from elsewhere.  A validation operation could ask the filesystem if it can
handle a particular filename, and fail gracefully.

Ideas anyone?

Feb. 14, 2000, Jeff Brown (x5625)