Skip to main content
  • EN

Hello!

 

Hopefully someone can answer this! For a bit of context, this pertains to FME Server version 2020.2.2. I am working on developing a script that will be triggered in an outside application and will use HTTP requests to send information to FME Server for processing.

 

I have a webhook set up for this and have verified that it runs successfully and the script is able to submit what it needs via an HTTP GET request. The thing is I also want to be able to automatically extend the token's expiry date through the same script. From what I understand, a PUT request would do the job...but I'm having issues figuring out how this part of the script would be authorized.

 

My first question is: does a PUT request require some sort of special API access? Any attempts at testing are being met with an "insufficient privileges" error message even though I'm the user/owner who generated the webhook.

 

My second question, which sort of ties into the first: since this is going to be executed from an outside script: does the HTTP PUT request somehow need the user account and credentials of the token's owner in the header, or is passing the token itself via "Authorization= fme token <token>" enough? I'm trying to figure out whether we somehow need to "hard code" the owner's username and password into the script for it to work - and the "insufficient privileges" error I'm getting is thwarting my testing.

 

Any help or guidance is appreciated!

 

Roberto

Hi Roberto!

A PUT request to update an API token should be successful with token authentication from the owner. Authentication via API token can be provided in the header or exposed in the query parameters. Find more instructions for doing this in Using a Token.

To find out why your account cannot update the token, please investigate the following:

  • Can you access the Webhook URL's API token from the Token Management page? Can you also make updates from there? If so, there may be a problem with the request configuration.
  • Can you test making the same update from a superuser account? If so, your account may have insufficient permissions to the workflow resources or user functionality.
  • Can you test the same updates from the REST API documentation sandbox, using either query parameters or body?
    • https://<FME Server URL>/fmerest/apidoc/v3/index.html#!/tokens/updateForm_put_4
  • If none of the above are successful, can you create a Webhook URL from a workspace in the Samples repository, then successfully update it's token? If so, your account may have insufficient permissions to the workflow resources.

 

However, for this workflow, does the client application need to update the Webhook URL token? One reason that API Tokens are secure is that they only provide access to specified items in FME Server. In order to allow a client application to make changes to tokens, it would need to have additional, administrative permissions. If security is a concern, my recommendation is to only embed and use the specified Webhook URL token in the client application. Instead, update the Webhook URL token from a separate and internal workflow. Alternative workflows to consider:

  • Hardcoding a suitable expiry date for the Webhook API Token from the Token Management page.
  • Creating a scheduled automation to update the API Token.
  • Creating a scheduled automation to send notifications when an API token is close to expiry so that it can be manually updated.

Hope that helps!

Hello Sanae!

 

Thanks so much for your reply! Yes, I think my regular user account just didn't have the proper permissions to the API (I'm not a 'power' user as I work in a different dept. from those who own the server). But I do want to thank you for your insight on handling the PUT request separately from an internal workflow. That makes perfect sense and I can't imagine how I didn't think of it in the first place.

 

Thanks!

Reply


Community Stats

30,095
Posts
114,253
Replies
37,725
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.