Visual LANSA Forum

I hope someone can help me with what is probably a simple answer.
We have built a series of Server Modules that use the XPRIM_HttpRequest, XPRIM_UriBuilder, XPRIM_JsonWriter.
The Lansa objects are compiled and checked into the iSeries.
All works great when we are signed on to the iSeries with our developer user IDs.
The issue is when a "normal" user is signed on and tries to execute the program call, and gets to the XPRIM requests.
We are trying to track down what the object is or what library is being referenced that the normal user does not have access or authority to?
The initial lib list for both our DEV user ID, and the normal user ID, are the same.
A difference in the profiles is one of the special authorities *ALLOBJ
If we add *ALLOBJ to the normal user profile, then it will work, but we do not feel this is the correct solution.

Does anyone know of Lansa documentation the specifically deals with user or profile authority for XPRIM objects?

In our server module, we have the pgm write out the incoming/return parms to a log file right before the XPRIM_HttpRequest, and then again right after, so we can see the request and response parm values. Request parm values are logged, but all response parms are blank, and the Lansa Http request logging doesn't even show that a request went out?

I would have thought something might have shown up in the xErr logs, but nothing that I can find?

By any chance are you using the trace facility. If so this dynamically creates trace folders based on the settings and if the running user is not authorised to the folder path the XPRIM command will silently fail without error. I have reported this to support. If this is the case the answer is to update the authority on all the folders in the path to *RWX/*ALL or don't trace for non-developers.

Update to issue for my own reference, and hopefully might help someone else.
Be sure to check each library/file, and IFS folder you might be accessing or writing to. I happened to miss one of the IFS folders used in the trace, but that wasn't the root issue.

So basically any time a call is made to an external server from the IBM i, with HTTPS, the remote server is checked against the DCM cert store.
If all you use is the *SYSTEM store, then any user profile that tries to access the DCM store will need *SECADM or *ALLOBJ special authority.

Options:
Create a new DCM store for your application, and remove the *ALLOBJ requirement.
Create your program with a pre-defined user profile that will run the job (not sure this is applicable in VL).

Since our VL Web applications were not experiencing this issue, but only why trying to integrate with our legacy programs (RPG), we chose to the use a program utility to intercept and change the user profile that runs the call to the API pgms. We created a special user profile just for this purpose with the *ALLOBJ authority, and pass this new user profile in to run the job.

Strange, none of our users have *ALLOBJ rights and we do not have this issue.