Re: [WEB400] Web development on the iSeries using CGI and the CGIDEV2library

[Mel Rothman <mel@xxxxxxxxxxxxxx>]

Mike, instead of sending your CgiDS to and from the browser, you could store it
in a user space on the host and send only the space name back and forth.

I use this technique successfully.  It is fast, easy, and secure.

Here's how I do it.
  1. Declare the data area as based.
  1. Store all user spaces, one per logical user session, in a separate
library.  This makes cleanup easy.
  2. When a new user comes in, use CGIDEV2's random subprocedure to generate a
new user space name, verify that a space with that name doesn't exist in the
space library, create the space (QUSCRTUS API), and make the space automatically
extendible (QUSCUSAT API).  If the name already exists, generate another name.
All of this could be written into one subprocedure.
  3. Retrieve a pointer to the user space (QUSPTRUS API), using the pointer
assigned to the based data structure.  At this point, all the data area's
subfields are in the user space.
  4. Process the user's inputs, storing any state information in the data
structure's subfields, and write output to the browser, including a hidden field
with the user space's name.
  5. Upon the next input from any user, if there is a user space field, use that
name to retrieve a pointer to that space.  At that point, the data area will
contain that user's information.
  6. When you want to end the user's logical session, send a response without
the user space name.  You could either delete the space or update a subfield to
indicate logical deletion.  In either case, you would have to write some code to
handle a user coming in with a logically deleted session.

The same CGI program running in a named activation group can handle many users
because each time it runs, it works with the data created for that user as
determined by the user space name.

I hope this helps.

Mel Rothman, CGIDEV2 Author
IBM eServer Custom Technology Center (eCTC), Rochester, Minnesota
http://www-1.ibm.com/servers/eserver/iseries/service/ctc/
http://www.easy400.ibm.it/en


Mike Skvarenina wrote:
>
> > > From: Joe Pluta
> > >
> >
> > Be careful here.  This is not a very secure approach.  While a user with a
> > browser may not be able to see or change hidden POST data, it's quite easy
> > for them to do a "view source" and copy the HTML into their own static
> page.
> > From that point, they can quite easily see and alter the contents of
> > "hidden" variables, then call the modified page up in their browser.  This
> > is equivalent to changing the URL on a GET request.  A little more work,
> but
> > not much.  And even if you do manage to hide the source (there are ways,
> > especially in DHTML), it's not that difficult to write an HTTP client that
> > can spoof POST data.  I'm pretty sure Brad Stone's GETURL goes a long way
> > towards that.
> >
> >
> Joe, excellent point.  There are a few other things we do to encrypt
> somewhat the CGICDS using a daily changing 'webkey' but I won't go into
> detail on how it's implemented but even that method wouldn't work if the
> person did this on the same day.  I havn't looked into ut yet but how can
> you hide the source using DHTML?  Also, I'll take a close look at Brad's
> technique as I need this to be as secure as possible.
>