Enhance the workflowAssistApps so that third party links can have a check access url

[ianwallen]

Enhance the workflowAssistApps so that third party links have a check url which can be used to decide if the link should be displayed to the user or not.

We require this option so that we can have it call a check url on our third party app to decide if the user has access to the link that we added. Otherwise some users are clicking on the link just to get an access denied page.

It adds the appAccessCheckUrl and it will follow this rule.

• If the appAccessCheckUrl exists then it will call it and check for success. If success then the link will be displayed.
• If it does return a success then it does an extra check for false values - i.e. 0, no, false.... If that was returned from the call then it will not display the link.
• And if the appAccessCheckUrl does not exist then it will always be displayed.

Here is a sample that was used for testing.

{
  "mods": {
    "workflowHelper": {
      "enabled": true,
      "workflowAssistApps": [
        {
          "appUrl": "https://www.google.ca/search?q={uuid}",
          "appLabelKey": "testkey",
          "appAccessCheckUrl": ""
        },
        {
          "appUrl": "https://www.google.ca/search?q={uuid}",
          "appLabelKey": "testkey2",
          "appAccessCheckUrl": "https://www.google.ca"
        },
        {
          "appUrl": "https://www.google.ca/search?q={uuid}",
          "appLabelKey": "testkey3",
          "appAccessCheckUrl": "https://www.bad.ca"
        }
      ]
    }
  }
}

It produces the following configuration.

And when viewing a metadata record, selecting

In this case testkey3 is not displayed because www.bad.ca returns an http 500 error.

[jahow]

using the HEAD verb would be more appropriate here, otherwise the client may end up downloading a lot of stuff

[ianwallen]

I originally used HEAD but then I did not like seen all the error message in the connection logs so I added the option to read the results from the body. If we do a HEAD term then we cannot use the body to check for text like "false, 0,,,"

I'm not sure if it is considered bad practice to check the body text or not? In our organization, we do have a couple API's that simply return an HTTP code 200 with "true" or "false" in the response body.

I can remove the body check and change it to a head request if that is best practice.

[jodygarnett]

My feedback after consideration - this approach makes me uncomfortable because it is a baked in SSRF as a feature.

If possible I would love to make a request from the security subsystem for a set of "roles", and change the check to a list of spring-security "roles".

[jodygarnett]

Thanks for fixing the test failure

[ianwallen]

In GN 4 there is a new page api.
It seems like the page api may be a better approach so I will investigate the page api to see if we can achieve the same results.

[ianwallen]

Hopefully the same logic can be achieved using the page api's

These PR's may replace this one.

• Group restrictions Enhance static page with group user accessibility  #7707
• Adding static pages to metadata menu static page for record view menu #7802

[CLAassistant]

All committers have signed the CLA.