IGNITe/400 Mailing List Archive Entry
Darin,

I use password protection extensively on my Insurance Company site with
three classes of user: Employees, Insurance Agents, and Policyholders.
Within Employees, we further restrict based on "functional area" (i.e.
accounting, marketing, underwriting, etc.).

What I have done is to first organize my server directory structure to
accomodate the three classes of user. The private areas are below a special
directory I call \private:

\server_root\
\public
\private
\employee
\agency
\policyholder

I use alias's like \employee for \private\employee
\agency for \private\agency
\policyholder for \private\policyholder

I then authenticate \employee, \agency, and \policyholder with group
authentication allowing GET POST and PUT methods for
members of the corresponding groups: employees, agents, and policyholders.

This means that a user accessing a page in one of the auththenticated
directories is challenged by the server for a user-id
and password.

Now, on to Net.Data.

I have created a little stub CL ILE program that calls Net.Data for me. I
call this NETDATA It contains exactly one line of code:
CALL QTCP/DB2WWW

It is compiled as a CL ILE program and specifies activation group = *CALLER
<<< CRITICALLY IMPORTANT -- wont work otherwise).
This is a limit of the SQL_CLI used by net.data. The SQL_CLI stores the
library and program name of the initial program which calls it (i.e.
DB2WWW). Subsequent calls from the same program in different libraries
fail.

I have created three libraries in the QSYS library system: WWWEMP (for
employees) WWWAGT (for Agents) and WWWPOL (for policy holders). Each of
these libraries contain: 1) A net.data INI file, 2) WWWADOPT (for I/Net
servers), and 3) my NETDATA CLILE stub program.

I define each library to the servers as CGI libraries. I also define alias'
to the server like:

/employee/cgi-bin/
/QSYS.LIB/WWWEMP.LIB/WWWADOPT.PGM/NETDATA.PGM
/agency/cgi-bin/
/QSYS.LIB/WWWAGT.LIB/WWWADOPT.PGM/NETDATA.PGM
/policyholder/cgi-bin
/QSYS.LIB/WWWPOL.LIB/WWWADOPT.PGM/NETDATA.PGM

What this does is fake the server into thinking that the net.data program
resides in an authenticated directory. This means that a user must be a
member of a valid group to access a macro called via the three alias's that
I have defined.

To further restrict and protect the server environment, each of the INI
files in the three libraries can point to separate macro directories
eliminating the possiblity that a clever user can call a macro from another
directory via the URL.

I maintain users by maintaining separate database tables that contain the
server user-id of the user and things like employee number, customer number,
etc. that identify the data that I will need to access for each class of
user. I have built a series of macros that let users create their own
user-id's and passwords. This invokes CL commands that add the user to the
server's user and group files, creates my database record, etc.

The way we do this is generate and mail (snail mail) a unique authentication
code to the user very similiar to the technique used by the big ISP's like
AOL, Prodigy, CompuServe, etc. when they register new users. The
authentication code is validated against our database to insure the user is
who they say they are and allows them to create a server based user id and
be added to the appropriate group authentication files.

hat point forward, I simply use the REMOTE_USER HTTP environment
variable to identify the user and look the user-id up in my user database
files to obtain their customer number, employee number, etc. that I use
within my macros.

Hope that helps.

Bob C.
-----Original Message-----
ign_list@ignite400.org [mailto:ign_list@ignite400.org]
Sent: Friday, October 23, 1998 2:06 PM
To: IGNITE400 MEMBERS LIST Mailing List
Password


Darin Dutcher

I have created a couple of sites with net.data that are not in productions
use yet. I need to password protect part of the site. Using both a
username and password I can think of a few possible options, but wanted to
know what has worked best for other people. The Sites will be running on
AS/400 4.2 or higher. Thank You for any help you might be able to provide.

Thanks,

Darin Dutcher
Huber and Associates

--- IGNITE400 MEMBERS LIST
Looking for staff or perhaps you want a new job?

news://news.ignite400.org/ignite400.as400jobs


Posted by  Subject  Date 

Return to the Mailing List Archive Page
Click to return to home page
© Copyright 1999 by IGNITe/400
This page last updated Sat, 21 Aug 1999 16:41:00