× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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?
--



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.