Hi Henrik, I believe your method of securing page to page navigation is something similar I was looking for. However, I'm not sure I understand where you store your requestfile. I primarily thought about using userspaces to do so since their names are randomly generated. Added an encryption to the userspace, it would be meaningless a safe to travel thru hidden input field. Then all the sensitive data regarding the request could be stored in the userspace along with some statistics. Our ideas look similar but the way to store the request doesn't. Your method look more volatile and self-cleaning isn't? Userspace requires a side process housekeeping (i.e. nightly job to delete obsolete US).
Regards Eric --- In [email protected], [EMAIL PROTECTED] wrote: > > > > > > Hi Marty, > > I have developed a complet request and security system for our > applications. > > Most of our clients are B2B environments and most of our applica- > tions reflects similar functions in the ERP system. > > We have 3 type of users ... > > 1. internal users - not bound to any accounts in the ERP system > 2. external users - bound to one or several accounts in the ERP system > 3. administrators of external users - bound to one or several accounts > in the ERP system > > The administrators og external users is of course because external users > are our client's customers or suppliers and they have several employees > that changes over time so they have to manage their own users and what > their users may or may not do, them selves. > > If there is one thing our clients management fears is that one of their > customers can sneak into another customers account. > > So therefore, I had to make sure that every request send from the browser > is impossible to alter. > > The way to do this is to generate a unique request id for every link, > buttom etc. and then store these requests whith the parameters nessesary > to do the processing ... > > My Requestfile looks like: > > Web Request 1198689696151117050106602363 > Web Cgi-Function wbdl04 > Web Session 0630043376151127050106602363 > Web Request IP Adresse 80.62.224.76 > Web Program Parameters 00000060022DM2006010000 > Web Time Posted 2006-01-05-15.11.27.636240 > > In the HTML the request looks like ... > > wbdl04.pgm?ses=0630043376151127050106602363&req= > 1198689696151117050106602363 > > the cgi-program wbdl04 will process customer(DM) accountnumber 60022, year > 2006 period 01 > for the user bound to the session 0630043376151127050106602363. > > The session number is generated at log in, and will be active as long as > there is > activity within a given timeframe. At log out every request is deleted and > gone > forever. This goes for PDF's and other files (even javascripts that may > access vital > information) the user have accessed during the session, they only "live" in > the apache > directives as temporary files bound to the session and all have > "unbreakable" nonsence > filenames. > > Both session and requestnumber are constructed by a number from the random > function, > the job-number from the cgiprogram that generated the request and a time > instruction. > > Furthermore I check that the user still have permission to the account, the > user still > is active and the user still have permission to run the cgi- program. > > If you try to alter the request, the cgi-program name or the session in the > HTML > you are OUT and your IP adresse will be logged in QSYSOPR message queue! > > Now try to figure another active users combination out. > > The reason I do not check the IP address is that it can change during a > session so > it is only informational, but can be user for a reverse DNS lookup if > anybody > tries to violate the system. > > Because I use this method not only when nessecary but all over and the RPG > code is > stored in copy modules and other programs the coding is quite simple ... > > Every cgi-program starts checking with: > > * Call Sequrity And Request Handler > c eval ZZWCgi = 'wbdl04' > c exsr RHdlr_Init > > To Create a request the code is: > > * Create New Request > c eval ZZrhdl = '*ADD' > c eval ZZwcgi = 'wbdl04' > c eval ZZwpar = ZZacno > c + ZZaccd > c + ZZyear > c + ZZperiod > c exsr Rhdlr_Exe > c eval Request = 'wbdl04.pgm' > c + %trim('?') > c + %trim('ses=') > c + %trim(ZZWSes) > c + %trim('&') > c + %trim('req=') > c + %trim(ZZWReq) > > And as a bonus I end every program with a call to the Sequrity > and Request Handler again. This will log the request and processing > time for tracking and statistical purposes in another file. > > * Output html to browser > c callp wrtsection('*fini') > * Call Sequrity And Request Handler > c exsr RHdlr_End > * Quit > c return > > This is of course only "the top of the iceberg" and what the cgi- programmer > has to do. There is a lot of files, maintenance and controle programs > etc.etc. > benidth. > > But it shoud give you a clue to how to create a security system that not > only > controls the access to the cgi-programs but also to specific data stored in > common files. > > rgds > Henrik > > > > > > > > "itpweb1" > <[EMAIL PROTECTED] > da.com> To > Sent by: [email protected] > [EMAIL PROTECTED] cc > ogroups.com > Subject > [Easy400Group] user validation and > 05-01-2006 14:24 page security, but do not want to > create user profiles > > Please respond to > [EMAIL PROTECTED] > ogroups.com > > > > > > > I have a question for CGIDEV2 developers who have developed (or > thought about) applications with a form of user validation and page > security, but do create a user profile for each unique user. > > That is to say, they do not want to use AS400(or NT/UNIX) > userID/password (with or without authorization lists) because there > are potentially too many users or have other business reason(s) not to > do this. > > My question is: what strategy of validation/page security are you > using? What are advantages/disadvantages of your method and is it > suitable for the WWW as well as a controlled intranet. > > ** Examples: > Validate against a PF list of user/passwords and pass a "user" token > variable from page to page, validate against IP address or other > environment variable, use the same password for everybody, create and > store a temporary cookie on the client which is verified on each page, > use CGIDEV2 persistence... > > Also is "too many users" a good excuse for not using as/400 user > profiles/auth lists to validate users? > > marty > > > > > > > Yahoo! Groups Links > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/Easy400Group/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
