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

Henrik,

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.

That's true, you can override it to another profile in your Apache config if you want. My point is it's the same for persistent CGI as it is for standard CGI.

Try it. If you don't set up the whole "Passwd %%SYSTEM%%, Userid %%CLIENT%%, Require valid-user" settings, persistent CGI will run under the QTMHHTP1 profile (or whatever you override it to) just as any other CGI job.

I do this every day.

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.

That's a good thing -- you don't want the profile people can get into without any credentials to have a lot of authority!

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.

Where did you get this from? How do you enable it? How does it work? Provide some information here, man. Apache doesn't serve FTP requests, and the IBM FTP server doesn't automatically sign you in when you're logged into Apache. What are you talking about?!

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?

If you are using browser authentication (i.e. BASIC or DIGEST) then the browser will automatically pass the userid/password across on all requests. Again, persistent and standard requests are the same in this respect, it doesn't do anything different for persistent vs. non-persistent... same would happen if none of your requests are persistent.

The security is exactly the same, here.

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 …

Using RPGOA for your display has nothing to do with whether you have bindings between the program that launches the UI and the one that processes data. You could be calling web services, stored procedures, etc to process the data... You could make it modular by breaking into modules, service programs, stored procedures, or web services... it's up to you whether you write your code in a monolithic manner or not.

RPGOA doesn't even require your program to be stateful. Most RPGOA applications are -- but this is primarily because people use it to allow them to run their programs with minimal changes.

There's nothing stopping you from making a stateless handler (and we include one with Profound UI). It can work exactly like CGIDEV2, except instead of WrtSection(), you call the RPG WRITE opcode. Then RETURN from your program and the data is written out via Apache to the browser.

It's a choice, not a requirement.