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 firstname.lastname@example.org Visit the on-line Midrange Developer forum at: http://www.rpgiv.com > -----Original Message----- > From: email@example.com [mailto:firstname.lastname@example.org] On Behalf > Of Mel Rothman > Sent: Saturday, December 22, 2001 10:18 AM > To: email@example.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: WEB400firstname.lastname@example.org > Before posting, please take a moment to review the archives > at http://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.