Re: In-house authentication & authorization

No it dosn't abandon (close down) the previous job, it works excactly as
the environment with a
generic user and leaves the job active but may terminate it by other users
requests for a new
QZSRCGI job.

http://5.103.128.110:6382/resttier0.png


On Sat, Dec 31, 2016 at 3:22 PM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:

Whenever a named user spawns a second CGI job, it seems like the first job
is abandoned, and I've always wondered whether it would spawn a third job
if the second was busy. Good to know that it would try to go back to the
first job.




-----Original Message-----
From: Henrik Rützou [mailto:hr@xxxxxxxxxxxx]
Sent: Friday, December 30, 2016 8:04 PM
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] In-house authentication & authorization

I'm afraid most have misunderstood how Apache handles QZSRCGI jobs because
it doesn’t switch user-profiles at any time other than when the QZSRHTTP
running under the OS user QTMHHTTP starts the QZSRCGI job.



QZSRCGI jobs are started under either the servers userprofile (QTMHTTP1 or
Apache ServerUserID) or if user access to the CGI directory/library are
validated under the OS under the OS user Id that makes the request.



In the latter scenario one OS user may own several QZSRCGI jobs witch is
normally seen if AJAX is heavily used due to AJAX’s asynchrony nature
(several requests may run concurrent from the same browser session).



If an OS user requests a QZSRCGI job Apache looks for an already allocated
idle job owned by the user in the server stack, if not found or busy a new
QZSRCGI job is started until the threshold for the Apache servers QZSRCGI
job is reached.



When this happens Apache will look for another user’s idle QZSRCGI job and
close it down and start a new QZSRCGI job for the requesting OS user. If
all is busy Apache will queue the request until it can start the new job.
This is a very time consuming process and must not be considered as
persistence CGI because it’s not.



Running CGI jobs under QTMHTTP1 is actually also a bad idea since the
QZSRCGI job and any underlying programs and object must give access to
QTMHTTP1. Running Apache under its own generic ServerUserID removes many
problems that may occur with QTMHTTP1 since the programmer controls the OS
Profile. This scenario gives the best performance on Apache since 3-5
QZSRCGI jobs may service hundreds of concurrent users depending on the
overall load - but it runs non-persistence which means that the QZSRCGI
jobs is left ‘as is’ from the previous requester and there are no guarantee
that consecutive requests from a single browser session is processed by the
same QZSRCGI job that may be busy processing a request done by another
browser.



The use of non-persistence Apache also requires some ‘home brewed’
security in front of every program in the CGI program library because there
are no such thing as a CGI program or in other words – any program that are
placed in the CGI program library becomes automatically a CGI program if it
has no mandatory *PLIST parameters that will require another program to
call it and any browser may access programs in the CGI program library
unless the is a security frontend that controls granted sessions and user
access to specific programs in the CGI program library.

On Fri, Dec 30, 2016 at 10:34 PM, Nathan Andelin <nandelin@xxxxxxxxx>
wrote:

Job start is an expensive operation. How do you maintain an
acceptable response time, or do your menu clicks just take a very
long time. Some

web

sites do, I am just wondering.

Job startup plus displaying an initial screen consumes about 20
milliseconds of CPU time. Even with the latency of the Internet, the
response is often sub-second.

After initial startup, subsequent requests typically consume 1 to 5
milliseconds of CPU time. Requests like generating PDF documents
require more time.

This architecture is supporting up to 50 million requests for dynamic
content per day in a production environment on a single IBM i server.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.