I'd be interested in your view on using the following technique instead
of purely a user space.

Consider an or website, literally millions of
visitors per day, with payment a few hundred thousand to a million
unique purchases per day (peak days).

Would creating hundreds of thousands or millions of Users Spaces objects
would be okay? I don't know the answer to that question.

Using a database file with millions of records presents its own issues.

So, what if instead of using a user space, you used a User Index with an
associated space? The "key" to the index would be the session ID, with
the data stored either (a) in the key as well if it was just a few bytes
of data, or (b) stored in the associated space via an offset within the

What do you think?

Bob Cozzi
Visit the on-line Midrange Developer forum at:

> -----Original Message-----
> From: [] On
> Of Mel Rothman
> Sent: Saturday, December 22, 2001 10:18 AM
> To:
> 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
> it
> in a user space on the host and send only the space name back and
> 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
> 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
> assigned to the based data structure.  At this point, all the data
> subfields are in the user space.
>   4. Process the user's inputs, storing any state information in the
> structure's subfields, and write output to the browser, including a
> 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
> the user space name.  You could either delete the space or update a
> 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
> 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
> > page.
> > > From that point, they can quite easily see and alter the contents
> > > "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
> > but
> > > not much.  And even if you do manage to hide the source (there are
> > > 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
> > detail on how it's implemented but even that method wouldn't work if
> > 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
> > 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:
> To subscribe, unsubscribe, or change list options,
> visit:
> or email:
> Before posting, please take a moment to review the archives
> at

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-2022 by 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.