Hello friends!
This question is focused on Pipeline Pilot installations that use BIOVIA Foundation to control security. I am observing a behavior in a protocol that I don't understand and would like to access the necessary arcane knowledge to work around the issue.
The protocol that I wrote is built to generate a PDF report of a Task Plan and all executed Tasks in that task plan. Since the report is going to be run via an automated process, it will use a service account that has read access to all collaborative spaces in our environment, but when I call RunProtocol.exe to run this report, I won't have any control over which collaborative space will be active during this initial authentication.
In order to get the current collaborative space, I call api/v1/collaborativespaces/\$current in a Hub Connector component:
And then directly query the Task Plan endpoint to retrieve the Task Plan details. If I get a 403 response, I know that I'm not in the correct collaborative space and then execute the switch by calling api/v1/collaborativespaces/switch with the appropriate JSON body in the POST and follow that up with a call to the redirect URI that is supplied by the API, which generates a new cookie that PLP for the new session. I can then successfully get the Task Plan details by accessing the runset endpoint, as shown below:
In order to get Task information I retrieve all executed Task work item URNs (these are pex urns) and pass those to a separate protocol to generate a PDF of the task execution (I can use the BIOVIA-supplied Recipe Approval Report or one of our own; the end result is the same). Whether I use a PilotScript-based RunProtocol command or use a Shortcut Component or drag the reporting protocol into this protocol, I get the same error:
Error running protocol '{3DF14AB6-ACA1-41E7-A190-829179962AB6}': HTTP request 'https://
HTTP Response body:
{"error":"invalid_grant","error_description":"Invalid refresh token: ab782f69-a30a-4ae3-baf7-f5951fec479f"}
This appears to indicate that the HTTP Connector components in the referenced protocol (or, protocol called via RunProtocol) are using the original authentication cookie from the PLP session rather than the updated cookie generated after the collaborative space switch. This is obviously not the desired outcome, and it's not clear to me how to ensure that I can run an embedded protocol using the current (updated) SSO cookie from Foundation.
Any help from PLP pros appreciated! And if this should be submitted as an SR, I can do that as well, but I wanted to give this community a shot at the problem first.
Thank you!
Marty
