From: otto@mail.olympus.net
Date: Tue, 12 Jan 1999 11:50:48 +0000

Proposal for:  Persistency Mechanism in Webkeystone

Project Description:
    Introduction:  Webkeystone has built in several security
    and persistency mechanisms.  The newid() function, 'TF_'
    files and several other mechanisms provide this, the
    problem is that:
      1.  There are too many mechanisms
      2.  They are hard to learn
      3.  Each one only handles a portion of the problems
          of a programmer in a 'stateless' system, such as
          the web.
    Past solutions have solved the technical difficulties, but
    not the difficulties associated with the programmers.
    Cookies and methods of passing secure file ID's are technical
    solutions only and don't really solve the higher level
    programming problems.  Webkeystone does solve some of these
    problems but could be improved.

    Proposal:  To write a new syntax and the corresponding code
    that answers most of the above needs.  This will allow the
    programmer to securely access a series of html forms and treat
    the invocations as if they were subroutines of the profile.

        Syntax:  Introduce a new command.  (Eventually this
        command will replace much of the 'TF_' file and
        newid() usage.)

        PERSIST  [,] [,]

        This command can be thought of as a call to a bye file.
        That is a call to an external html form.  In this sense
        it works very similarly to the old RETURN command.

        It differs in several respects.  First, when the
        form is submitted, a new profile is not loaded, but
        control returns to the line immediately following the
        PERSIST command.  In this sense it works like a CALL
        command.

        In order for this to work, the byefile containing the
        form must contain a hidden field of the form:

        

        This is the only hidden field required.  The variable
        'persist_' is assigned transparently and the replacement
        is always made.  The variable is niether readable nor
        writable by the programmer but is set by the webkeystone
        system.  The value of persist_ will be a 16 character
        or longer nonsensical and unguessable id.  The old hidden
        Profile and UserID fields are not needed and should not
        be provided.

        The dictionary command, if included, contains a dictionary
        of all of the fields collected from the form.  It is
        generated exactly as the current name space for profiles
        is generated and contains the same information and
        validations.  It is returned as a dictionary so that
        the new values from the form do not pollute the old
        values of variables in the Profile.

        If the optional time limit is not provided, the system
        will default to some value. (most likely 15 minutes.)
        The byefile form must be submitted within
        the time limit or an error will result.  This is necessary
        to prevent pending operations from accumulating.  This
        is the same rational used in the current "TF_" file
        mechanism.  The webkeystone system will cleanup old
        pending requests that have expired.

        By wrapping all of the persistant information with a single
        long ID value we both simplify the system and maintain 
        security.  The validation of a user is made at one point
        only in the system.

Assumptions:
    This assumes that Otto can rewrite the necessary parts of
    the code efficiently.  Some testing needs to be done to
    verify that the above is achievable without breaking any
    of webkeystones current capabilities.  The above assumes
    that the above is in fact a simpler and more complete syntax,
    please comment.  The above assumes that everything can
    be achieved in Python alone.

Requirements:

Comments Requested