Re: 'green screen' not sellable --> WE(?) are the problem

Scott



“The way it works is that if you don't sign in and give a user profile,
CGI programs use QTMHHTP1 for the OS user profile, and that's used to check
access... it's exactly the same with persistent CGI as it is with regular
CGI.”



This is simply not correct QTMHHTP1 is only used as default, if you
specify ServerUserId in the Apache conf. file the QZSRCGI jobs run under
that adapted user profile in the stateless environment.



QTMHHTP1 is the most “shitty” user profile in the system. It has no way
accessing files through QNTC since has no password and it has the lowest
access to any IBM I objects.



“I don't understand the bit about FTP services -- persistent CGI has
absolutely nothing to do with FTP, and in no way grants users’ access to
FTP.”



If you validate users against *OS in the Apache directive you are able to
use the same user id/password to get access to FTP (or other services) if
it is open for public access.



“You wouldn't use a persistent session for AJAX... Persistent sessions
are only activated when you send a special HTTP header, so with each
request you can tell the server if it's to use the persistent session or
not. In Profound UI we use a mix of persistent and non-persistent CGI.
The persistent stuff is done for Open Access where the RPG program is
sitting on an opcode like EXFMT waiting. When AJAX calls are made from
customer's applications, it doesn't use persistent. These mix together
seamlessly and work very nicely.”



You may be right, but how do this ensure security in the AJAX request
without delegating access from the persistent session to the stateless AJAX
requests?



Well you run stateful RPGOA, I run stateless SOA from EXTJS SPA’s – two
different things and designs. You keep state to a 5250 like environment for
every user; I launch SPA’s from one program and let the client SPA handle
server communications independently using stateless generic REST/CRUD
services where every SPA that is launched grants specific access and
parameters to the REST/CRUS services it uses.



At the same time I can delegate sessions to the traditional *OS
environment by exchanging OS handles with an API written by Niels Liisberg
(Icebreak) – but it is, as I wrote, the other way around – my stateless
environment runs stateful under the hood but that is another discussion.



In RPGOA you have bindings between the program that launches the UI and
process data – I have none now we also are talking about monoliths)! You
have bindings to the controller that runs on the server – I have none since
the controller is entirely based on generic javascript configured by the
initial program that launches the SOA and configures it by passing
javascript/JSON objects to it at load time with a little twist …



JSON is actually today used to inject and expand javascript into running
OO javascript objects. But this is far beyond the present discussion but
also a requirement if you want to run SPA.

On Fri, Jun 12, 2015 at 12:08 AM, Scott Klement <
midrange-l@xxxxxxxxxxxxxxxx> wrote:

Henrik,

Your first two points (must have an OS profile, must have OS object
access) is not exclusive to persistent CGI. It's true of all CGI, and
indeed, all HTTP access through Apache.

The way it works is that if you don't sign in and give a user profile,
CGI programs use QTMHHTP1 for the OS user profile, and that's used to check
access... it's exactly the same with persistent CGI as it is with regular
CGI.

I don't understand the bit about FTP services -- persistent CGI has
absolutely nothing to do with FTP, and in no way grants users access to FTP.

You wouldn't use a persistent session for AJAX... Persistent sessions
are only activated when you send a special HTTP header, so with each
request you can tell the server if it's to use the persistent session or
not. In Profound UI we use a mix of persistent and non-persistent CGI.
The persistent stuff is done for Open Access where the RPG program is
sitting on an opcode like EXFMT waiting. When AJAX calls are made from
customer's applications, it doesn't use persistent. These mix together
seamlessly and work very nicely.

I have never seen a job closed down when reaching MaxCGIJobs. What
happens is that no new jobs can be started, causing poor performance -- but
it does not shut down the existing ones.

With regard to the problems of keeping many jobs active for
statefulness... this part, at least, we can agree on. This can be a
problem, but consider this: It's no worse than having people use 5250
emulators (which also require a job to be kept open all the time.) So if
you are migrating from a 5250 application, you aren't losing anything
here. We have customers running 10000 simultaneous users this way, and it
works well. Granted, they do need to make sure they tune their system,
have sufficient memory, network resources, etc... but once set up properly,
it works great.

Of course, for a public facing web site (as opposed to a business app)
when you can't control how many people will hit the site at once, you're
much better off not using persistent CGI, which is why we offer
alternatives. We have both persistent and non-persistent ways of doing
things, use the right tool for the job.






On 6/11/2015 4:53 PM, Henrik Rützou wrote:

Some more remarks about Apache persistence CGI jobs.



* Users must have an *OS user profile, in many web applications users
don’t.

* Users must have *OS object access to all objects used in the web system

* Users also gain access to other services that run on the server such as
FTP etc. unless extensive user controle is applied.

* Using internal user profiles and passwords in a web system that may be
accessed by a browser from any device opens for sniffing.

* Persistence is only pseudo persistence as described earlier

* Persistence is not designed for concurrent AJAX and may cause
unpredictable results. You will either need to remember to set the async:
false property in the AJAX request or has an AJAX queuing mechanism in
your
web application.

* Jobs are closed down when MaxCGIJobs are reached causing closing and
reopening of programs and files and also loosing persistency and causing
poor performance.

* Persistence requires large pools of active IBM I jobs that even if they
are paged out of memory into the memory disk based work area takes up
resources.

On Thu, Jun 11, 2015 at 11:44 PM, Holger Scherer <hs@xxxxxxx> wrote:

that's the reason i put some entries into my hosts file like

127.0.0.1 facebook.com

;-)



Am 11.06.15 um 23:43 schrieb Henrik Rützou:

This is not hidden in a cookie it is delivered by google addwords

--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
Regards,
Henrik Rützou

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