Re: Processing Ideas Needed:

on 26-8-2007 9:00 Richard Maher wrote...
You'll have to forgive me as I rarely pay much attention to anything Bob G
has to say (especially stuff such as "Shareable image installed with the
needed privilege.") but when it comes to the application of your/Bob's
solution to Chuck's problem, can I ask you to clarify a couple of things for
me: -

I am a forgiving person(a).

1) How does Chuck's Webserver assume the "only (1) particular user id", and
the associated identifier, whilst handing over to the image activator in
order to run the Executable installed with privs?

The webserver does not assume anything. It causes a process to be created for user JANEDOE, who is not privileged, but happens to be associated with a rights identifier RUNANIMAGE, so she's able to run an image that SUBMIT/USER's a job.

2) Does it create, and rundown, a new VMS process for each client request?

I hope so.

3) Does it use some dodgy inner-mode personae that manages to survive image
rundown?

No.

4) Does it keep the process lying around in case the (1) user id is needed
again?

No.

5) Where does the logfile go?

The webservers log file is where it always is, and records the run request. The /OUTPUT, /ERROR qualifiers of the RUN command determine where those log files go. The SUBMIT/USER command causes the log file of that job to go to the /USER=xxx login directory.

6) Has non-interactive logins for (1) user id been clicked over?

Not sure that it's relevant, but "No". The user JANEDOE exists for one purpose only, to SUBMIT jobs. Her VMS "account" should, maybe by being CAPTIVE or by other standard issue modifiers, restrict her to berform only that function.

7) How does the success (Job entry number, perhaps pending status, or
execution queue) or failure get returned to the user?

In this our stateless universe, I cannot think of a way to do this synchronously. So, write it into a file, and tell the user to check back on the status later. My favourite web shop does it that way, I can live with it.

8) If (1) user id decides to submit the job again, does he have to enter his
username/password again or is it held in some dogy cookie or session
variable?

Preferably not.

9) What sort of expiration time do you put on that crap?

See above, none.

10) What window of opportunity for Session Hijacking is good/small enough?

Also, N/A

Yep, welcome to VMS development! What have we had so far? FAL jobs with
proxy usernames, Cookies, Session IDs, New processes (let alone image
activation) for each request, and polling for file existance. (I'll throw in
the inevitable "Use ODBC and an external function to the submit the batch
job and put an ACL on the function") All of this brought to you via HTTP and
a codepath that would tempt Alexander the Great to reach for his sword!
Funnily enough, I suspect that all Chuck wanted was a RPC.

Yeah, and from my point of view, this is what he gets. Unless he wants to submit a million jobs a day, process creation is not an issue. We'll walk that bridge when we come to it.

/Wilm
.