LoginOut provides an application-based (as opposed to an HTTP-based) solution for web login and logout. The sources and the executable code needed to implement this approach are in library LOGINOUT. The code is made of:

• a validation list maintenance utility (CGI program WRKVLDL)
• a validation list (LOGINOUT)
• two sample programs (CGI programs SAMPLEPAG1 and SAMPLEPAG2)
• a service program (LOGINOUT)

The approach relies on a validation list and a cookie.

1. Validation list
   The server must be able to validate authorized users. Some file containing information about authorized users should be made available. Why not using a validation list for that? Validation lists are the perfect object type for such a duty:
   • rather compact objects
   • provide high performance access
   • cannot be accessed with traditional tools/utilities/comands
   Of course, you need a program to maintain validation list entries. This is CGI program WRKVLDL in library LOGINOUT. See page Defining users to know how to use it it.
2. Cookies
   Non-persistent CGI programs are stateless (they do no retain a reliable memory after processing a user transaction). Therefore, every time a non-persistent CGI is called, it must perform user validation again. In other words, something external to the CGI must provide every time an user identification. The application driven technique for this is to give the client - as soon as the user logs in - an "identification-ticket" to the client. From this moment on, any time the client calls a CGI, the CGI can ask for the ticket and perform user validation.
   To support a ticket strategy, nothing is better than a cookie. Cookies are data areas on the PC. All cookies referring to a given server are returned in a single environment variable at any CGI transaction. This is why CGIDEV2 service program can easily retrieve a cookie of your choice.
   The identification stored in the cookie is made of the username and of the password. The CGI, after retrieving the cookie, will have to validate this identification versus the validation list (don't worry, we provide functions in a service program to perform such duties).
   The debatable question is "how long a cookie should lasten". We have decided for a temporary cookie. A temporary cookie is a cookie that expires either when the user logs out from the application, or when the user closes all the browser windows. Should you like a different approach, for instance a cookie that stays on forever, or for a couple of days, unless the user logs out from the application before the cookie expiration time, that can be easily implemented by just changing a statement in the logon program.

A sample walk through
Library LOGINOUT contains a prototype CGI application that you may adopt in developing your own CGI applications (see page "Application development").

To make it work, you should first add at least an user of your choice (user name and password) to validation list LOGINOUT/LOGINOUT. See page "Defining users".

Let us have a walk through this prototype.
The prototype is made of two ILE-RPG CGI programs (powered by service programs CGIDEV2 and LOGINOUT): programs SAMPLEPAG1 and SAMPLEPAG2.

1. The login program
   This is program http://.../loginoutp/samplepag1.pgm
   This is how this program works:
   1. Ask for login
      

      When no input variables received, the program sends out a login form (Figure 1)

      Figure 1 - Request to log in

   2. Perform the login
      If the program receives the login request, it
      • validates the login data versus the validation list (if the validation fails, it issues again the request to login with some error message)
      • sends out an html page which
        • donates the temporary cookie to the client
        • sends a request for CGI program SAMPLEPAG2 to the server
2. The next page program
   This is program http://.../loginoutp/samplepag2.pgm
   This is how this program works:
   1. User validation
      The program receives user name and password from the cookie, and validates this identification against the validation list. If the validation fails, it issues a page that sends to the server a request for program SAMPLEPAG1 (no input variables provided). As a consequence, the log in page (Figure 1) appears.
   2. Perform application logic
      This is what a real life application program should do. In this example, no application logic is run.
   3. Send out the reponse html page
      The contents of the page depend on the application. All application pages should however feature a logout button: see Figure 2.

      Figure 2 - An application page

      The logout button sends a special request for program SAMPLEPAG1. This program will send out an html page that:
      • makes the cookie expire
      • sends a a request for program SAMPLEPAG1 (no input variables provided). As a consequence, the log in page (Figure 1) appears.