Allow app authentication for the workflow designer REST API
We are using the Workflow REST API to automate execution of workflows, but also to download and upload the workflow JSON, for automated backup or migration purposes. Currently, this works with user credentials (username + password).
But rather than having to store user credentials somewhere, I'd like to use an app login (i.e. an app defined in Portal with a clientId and clientSecret). This works for running a workflow, but not for accessing the /designer endpoints. I can see that a designer token is successfully created, but the /service/designer/workflows?id=[ID] endpoint returns GW001.403: Access Denied.
-
Hi Berend,
Make sure you're including the Authorization header. Here's how it looks when we fetch a server workflow from within the designer:
const response = await fetch(openWorkflowUrl, { method: "GET", headers: { Authorization: `Bearer ${this._designerToken}`, Accept: "application/json", }, });Also, you might be interested to know that this endpoint accepts an optional querystring parameter called “revision” which is an integer number ≥ 1 that returns a particular version of that workflow. By default we return the latest save, but we keep every saved version. You can see the revision numbers included in the file names saved within
C:\ProgramData\Geocortex\Workflow\Workflows. We never fully implemented the feature but you're welcome to experiment with it if it interests you.0 -
Ken Lyon Thanks, that is what I do already, but the result depends on how the ArcGIS token is generated.
A (ArcGIS) token generated through the interactive OAuth user login flow works, but an app token generated from the /oauth2/token endpoint does not. With both options I can successfully get a Workflow designer token, but only the first one works for downloading a workflow.
If I create a token using the /generateToken endpoint, I can't get a Workflow designer token at all.
Getting a ‘run’ token and executing a workflow works in all three cases.
Does the app I create in ArcGIS need to have certain privileges set?
0 -
Berend Veldkamp This is getting a bit complicated. Let me try a table to see if I've understood what you're saying…
Method Gets Designer Token Downloads Workflow
OAuth (Interactive) Yes Yes
/oauth2/token Yes No
/generateToken No No (implied)Firstly, there are a few reasons a token might be rejected when requesting a designer token:
- The access token was not generated using the correct App Id.
It has to match the Portal settings in the Workflow Post Installer. - The user does not have permission to access the app.
I'm not clear on how you could generate a token for something you don't have access to, but we do check both things
Some reasons why a designer token might be rejected when trying to download a workflow:
- The key embedded in the token doesn't match the one in Workflow Server.
This might happen if it's expired. If you're using the token immediately after generation it should be fine. - Again, the App Id needs to match.
In your case, you wouldn't have got the designer token if it didn't. We do check for it here, though. - You need write permission on the portal item associated with the workflow.
If you are comfortable sharing the two designer tokens with me, I could dig into them and compare them. Maybe I could spot a difference between them which would explain why one works and the other doesn't.
0 - The access token was not generated using the correct App Id.
-
Ken Lyon
Thanks, I compared the ClientID with the one in the post-installer, and it's indeed the one I'm using. I am also the owner of both the app, and the workflow.
The app is not shared (Owner only), but sharing with Public or Organization does not make a difference. Should it be shared at all? And what about permissions set in the app, should I include Create, update, and delete there? Changing it doesn't seem to do anything
This is a token generated by /oauth/token (does not work):
eyJhbGciOiJIUzI1NiIsImtpZCI6IjU0N2U3NzZkZGM2YzQzZjZiN2EwZTVjYmI3MTkzNTY1IiwiemlwIjoiREVGIn0.bY_LcoIwGEbf5Z8uQUHu2XFRqiheRtSuOhFTQEOIJFWp47t32k676vZ8Z_GdO-QNA3SHJ9lxAggmVxkRURWMtGHDJGESFOBNKzEdHwDB8nmd18Z5oiXLbenh7G_NWgoISim5QP0-o7gWWOiG3hNXkjc9Qfo_HiiA85wIsW5OhAGC2Fs4mu_WScot99CWbmxbJKHsxU20jzgrNrSUe7xInWNhX4YXPKzS7GhlM7_2jbfWW_rzsWdGexoSdx2PrN02UZPqvIm0iKptYIvDrghnwaXTKxmm59Hras5XJ2e674LB5l2dsq9DnP8f91CgwhKQ7niG4ZgDyzRMRwFy47_M1r7Z4xM.oD41p0ilFSChi6Xfnzsstv3ITcb25omSTK3rr0Pg3rYAnd this one is interactive (works):
eyJhbGciOiJIUzI1NiIsImtpZCI6IjU0N2U3NzZkZGM2YzQzZjZiN2EwZTVjYmI3MTkzNTY1IiwiemlwIjoiREVGIn0.dZFBc6JAGET_Smpqj6KMgAI346qALoKLErxQI4wrAsPAN4Cayn9PJbubW67v9aW7X1FSMWS-oh_izikykdOLnxSyP4w284oJygQaIF41ghR2ikzkW0FSKrUjr_3wYpD9l903BTLRRQgO5mjEClICAazgIfQ0qYZAR39zaIBIklCAoMopQyZaGd5Ununl2uWanjYXfTXR6Oba9vYRSnfDyHbW1fbtXPRL0E6SLC0gXm_CXPHCGiJc2XXsn2j54gl-wHmo3vxASn2Ms9Zbzrxjr3bLZSQUKI7ZXozdA3u2LPkKXX6ob1qt3baXxHL7MXlORCxFvvpQteAe6DaX77t0wRdt3dyjx3mXa3oht9eTM8EPWHHD1XdyYNeWWMV81_NrGP-KGGT-i3ROzuO5ZaTbOva7oHeNfSU7VM2r4Ud5zr8bsgXafLpZ2mVA2wb_gy4pP775LbKSQ8WenOHTnAj0NkAZEcjEU0NRpqqiyuOJMkD0xv-zCf5kb-8.-1gPyXSZrPXZAOhyQZh4Iw7OQ8mnIeChGS80FFrzGoYI'd appreciate it if you have the time to take a look at them.
0 -
Berend Veldkamp
I was able to inspect these two tokens and I found some discrepancies.
First of all, the things that were the same were:
- AppId
- PortalId
- PortalUrl
The things that were different were:
- AccessToken - The one that does not work is considerably shorter. (128 chars vs. 236)
- UserId - Only present in the one that works.
- UserName - Only present in the one that works.
I'm not sure that gets us much closer to a solution, unfortunately.
It seems to be a discrepancy between the two ways Esri lets you generate the token. Maybe there are limitations in what the /oauth2/token endpoint will provide?
I see in this page that there's a difference depending on the grant type you're requesting. Maybe one of the options returns a token containing more details.0
Du måste logga in om du vill lämna en kommentar.
Kommentarer
5 kommentarer