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

["Bob Cozzi \(RPGIV\)" <cozzi@xxxxxxxxx>]

Mel,

Great idea, I'm going to consider stealing it for this new app I'm
writing.
I was considering creating a database file that did, effectively, the
same thing using a session ID. Then just chain out to the file to see if
that session ID was there.

But the advantage I see in using a user space is that by getting a
pointer to the user space (using the API) you can map its data into that
Based() data structure, and effectively you've externally described the
data structure.
And, if you put a date/timestamp in the user space, you could easily
write a clean out program that just went out and deleted user space
object with a time stamp older than X.

The other advantage is you can add additional fields to the data
structure without the need to create the database file. While that might
not be too be an issue for some, in which case they may want to consider
using a file, for other with high-transactions per hour, you could
recompile your program with the next data structure layout, and put it
into production.

Bob Cozzi
cozzi@rpgiv.com
Visit the on-line Midrange Developer forum at: http://www.rpgiv.com


> -----Original Message-----
> From: web400-admin@midrange.com [mailto:web400-admin@midrange.com] On
Behalf
> Of Mel Rothman
> Sent: Saturday, December 22, 2001 10:18 AM
> To: web400@midrange.com
> Subject: Re: [WEB400] Web development on the iSeries using CGI and the
> CGIDEV2library
>
> 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.
> >
> _______________________________________________
> 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.