Zend/PHP/toolkit authority issue

[gcraill]

Heya,

We have a program which has *OWNER authority and is owned by a profile with *ALLOBJ, and the program does all sorts of stuff including some SQL updates to files in a library. So it runs fine on the green screen and does what it needs to do.

I want to run the same process from the web, so i need the call to adopt the authority of the owner of the program being called ...

When I invoke it from the web page using the XTOOLKIT under profile QTMHHTTP it fails with an authority error on a library. The library is secured by an autl. When i add QTMHHTTP to the AUTL it works from the web. But I didn't want to open up the libraries to allow access directly from QTMHHTTP.

Is there any other way I can do this?

[DeadManWalks]

Re: Zend/PHP/toolkit authority issue

Thats how authority works. if QTMHHTTP can not use the lib, then its doa. Now if you use adopted authority of QTMHHTTP to the owner of the lib then you will get it.

[MichaelCatalani]

Re: Zend/PHP/toolkit authority issue

You can call a program that uses the QWTSETP (set profile) to swap the profile to one that is in the authorization list, and then have that program call the intended program. That being said, I really wouldnt like the idea of allowing a job to adopt *allobj, especially one that is executing SQL statements.

[tomliotta]

Re: Zend/PHP/toolkit authority issue

I'm not involved in Zend/PHP at all in what I do, so I can only make some guesses. But one thing could need some clarification.

When I invoke it from the web page using the XTOOLKIT under profile QTMHHTTP it fails with an authority error on a library.

You say "it fails". What fails? Is it an instruction in the called program that fails? Or is it the invocation that fails? That is, is the program successfully invoked and then it fails after running part way, or does the invocation fail because the program library isn't authorized?

[chris_hird]

Re: Zend/PHP/toolkit authority issue

The Easycom i5_toolkit has a number of ways to get round this, the one I have used in the past is to connect then use the i5_adopt_authority().

You can collect the user name and password over a secure link or use something similar to the following post.

http://www.shieldadvanced.com/Blog/application-modernization/time-taken-for-password-encryption

Chris...

[gcraill]

Re: Zend/PHP/toolkit authority issue

@Tom - The message was "Not authorised to library xxxx", yet the pgm *OWNER had *ALL authority to that library and it worked from green screen command line just fine.

@Chris - will have a look at that, thanks for the link.

Our security boffin (John) figured out that this solved it for us.

The AUTL that wassecuring the library had to have OPR access to QTMHHTTP. Then the program (which uses *OWNER and has authority to the lib via that owner) works.

I don't profess to understand it ...

             Object    List  ----------Object-----------
User        Authority  Mgt   Opr  Mgt  Exist  Alter  Ref
*PUBLIC     *EXCLUDE                                    
QTMHHTTP    USER DEF          X

[tomliotta]

Re: Zend/PHP/toolkit authority issue

@Tom - The message was "Not authorised to library xxxx", yet the pgm *OWNER had *ALL authority to that library and it worked from green screen command line just fine.]

My question was intended to determine what received the error exception. If PHP received the exception, the problem could be very different from the *PGM receiving the exception. If PHP received the exception, it probably would make no difference if the program was *OWNER or not. The *OWNER attribute would only matter after PHP had successfully invoked the program.

Until successful invocation, *OWNER has no effect at all. But if PHP (i.e., QTMHHTTP) isn't authorized the the program library, it wouldn't matter how the program attributes were set. The program would never start.

When that attribute is set for a program, *OWNER becomes effective after:

1. The program is successfully started, and
2. The program attempts to access an object or perform an action, and finally
3. The job (or current) user authority is insufficient.

Until those three elements have happened, the program runs under *USER authority. (That's the basic sequence. Numerous details could be added.)

[gcraill]

Re: Zend/PHP/toolkit authority issue

Clear as Tom!
I may not have been tho -
I should have mentioned that the program was successfully invoked via the web as the other 9 tasks completed ok as expected, it was just that one library was locked down to public(*EXCLUDE) so the *OWNER attribute on the program (which was owned by an *ALLOBJ profile) was expected to work. The error message was on the XMTOOLKIT job (part of the zend stuff)