RE: HTML/JavaScript design question

Why even show the user the CDS at all? It sounds like you want sessions.
This is a general session ID passed through the browser, as opposed to the
"session" caused with persistent connection.

In general, during the signon process, we generate a session ID. (an MD5 of
the User, password, job number, current date and time). The session ID is
the key field to the SESSIONS table. The data portion is variable length. At
the end of each CGI program, write the CDS to the sessions table. Each link
in your programs will refer to the session ID generated during the signon.
Each CGI program reads the session data from the SESSIONS table.

Where you would store the CDS in a hidden field, put the session ID there
instead.

The biggest drawback to this approach would be database access and if the
user backs out of pages.

HTH,
Loyd

-----Original Message-----
From: Michael Skvarenina [mailto:mskvarenina@usa.net]
Sent: Wednesday, May 29, 2002 2:45 PM
To: WEB400@midrange.com
Subject: [WEB400] HTML/JavaScript design question


This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
We've been coding RPGCGI apps for almost a year now with great success.
Recently we've entered into a debate however as to the best design model for
passing variables (selections) back to our RPG server programs.  We are
looking for comments from the group on the 2 methods we use as well as
additional suggestions.  Hopefully this won't be too confusing as I try to
explain:

First we created a data structure we call the CDS or "Common Data
Structure".  This CDS contains a bunch of different fields that we pass
around during a CGI session.  For example, when a user first accesses our
Web system they login which is basically a call to a validation program.
The validation program fills fields in the CDS such as their userID, name,
workstation they logged on to, etc then builds the next page.  For each form
we return, we include this CDS as a hidden field.  Later when a subsequent
form is submitted, the CDS is passed back to the server and used as needed.

Now, lets say we're doing a paging application where we are listing
employees along with a pager icon.  A user clicks an icon and gets a screen
to enter a message.  That's on the high level.  Now for a little more
detail, we have a RPGCGI program that handles the paging.  We have many
programs that can link to or "call" this program.  One program for example
is a telephone directory style program where we list each employee and
include a pager icon if they are pagable.  A second program is linked to our
Time and Attendance system which shows employees currently signed-in
(meaning they are are work, signed in to the T&A system).  This program too
includes an icon and can link to or "call" the paging program.

We designed it this way so we could have a modular approach and not rewrite
the paging code for each program that needs to send a page.  Basically if
it's called, all it needs is the CDS (so we know who's requesting to send
the page) and the pagerID to page.

Here's where the design question comes in.  Historically in our HTML we'd
make up a form that contained the hidden CDS and also include variables
specific to the program that would be called.  The we'd reference this form
through a JavaScript function.  So in this case we'd have a form with the
hidden CDS and the hidden pager number to page.  We'd have a function, lets
call it SendPage that accepted a parameter (the pager number) and this
function would set the hidden variable field them do a form.submit.

Recently, one programmer did a different approach.  He embedded the entire
CDS into the function call and embedded the pager number into the CDS.  The
when the function was called it simply passed the entire CDS to the form
then did the submit.  This works but I think passing only the relevant data
in the function call is better.

For one thing we are aware of HTML spoofing (I think Joe Pluta actually
pointed it out months ago) and although we don't think we can prevent it one
solution I am toying with is writing the CDS out to a cookie and furthermore
encypting the CDS when we write it, then decrypting it when we read it.  If
we embed the entire CDS into the function call this may not even be
possible.  Also using the cookie approach does better hide the CDS data from
the typical user meaning he won't be able to simply view the source and see
the data.

Comments?
--

_______________________________________________
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/web400
or email: WEB400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.