Skip to main content
Solved

FME Server - API call fmerest/v3/transformations/transact/ with no autorization header

  • September 27, 2019
  • 7 replies
  • 35 views

lazarlubomir
Contributor
Forum|alt.badge.img+10

Hello everybody,

please, I met one issue with running the job on FME Server - is there any way, how to submit a job to run without authorization? How could I configure call to run like that?

Now I use this API call to submit a job to run - fmerest/v3/transformations/transact/.

 

Thank You so much!

Lubo

Best answer by hollyatsafe

Hi @lazarlubomir,

Since we were able to come to a resolution through a case I just wanted to share our findings here as well in case anyone else is looking for answers on this.

The main issue you were having is that you needed the Token to change everytime a request was submitted as you were using this token as a unique ID to name files/folders in your workflows as well. However this became a problem when you introduced parallel processing of requests because once a new ID was generated, any requests still needing to be processed with the old Token failed with an authentication error.

This is because in FME 2018.1 and older users are only eligible to have one session token at a time. Therefore in order to overcome this there were two options:

1. Give the guest account permissions to the repository containing the processing workspaces, this will remove the requirement for authorization via a token and the the workspace and data download requests will be able to run with unauthenticated access, but you can still generate the tokens to be used for file names (https://docs.safe.com/fme/html/FME_Server_Documentation/AdminGuide/Configuring-Authentication-for-Security-Resources.htm)

 

2. Generating a single token to be used for all requests that has a long expiry date and then using another method to name your files, a timestamp or UUID perhaps.

Alternatively in 2019+ the Token Management service was completely redone and now supports multiple valid session tokens created by a single user, meaning you could continue generating a new token for each series of requests and have these running in parallel.

View original
Did this help you find an answer to your question?

7 replies

david_r
Celebrity
  • September 27, 2019

Why not simply create a user token with a maximum validity and use that?


lazarlubomir
Contributor
Forum|alt.badge.img+10
  • Author
  • Contributor
  • September 27, 2019
david_r wrote:

Why not simply create a user token with a maximum validity and use that?

@david_r,

because It is more complicated. Whole solution is based firstly on POST call to retrieve valid TOKEN, everytime via the same user. This user after that can upload files to server thanks to valid token and then he can submit a job to run with authorization. But what if calls come very shortly after each other?

Just imagine situation:

13:15:12 - User XY (used by another app) sent POST to get valid token - he gets token 1234

13:15:13 - User upload files for run a job to server, with authorization

13:15:14 - User XY sent POST to get new valid token - he gets token 5678

13:15:15 - User with token 1234 gets HTTP 401 Unauthorized, because different user who used the same app, but makes another call, got a new token

 

Token number is very important parameter, because at the end of job run, there (in path for data download) is created folder named by token value.


david_r
Celebrity
  • September 27, 2019
lazarlubomir wrote:

@david_r,

because It is more complicated. Whole solution is based firstly on POST call to retrieve valid TOKEN, everytime via the same user. This user after that can upload files to server thanks to valid token and then he can submit a job to run with authorization. But what if calls come very shortly after each other?

Just imagine situation:

13:15:12 - User XY (used by another app) sent POST to get valid token - he gets token 1234

13:15:13 - User upload files for run a job to server, with authorization

13:15:14 - User XY sent POST to get new valid token - he gets token 5678

13:15:15 - User with token 1234 gets HTTP 401 Unauthorized, because different user who used the same app, but makes another call, got a new token

 

Token number is very important parameter, because at the end of job run, there (in path for data download) is created folder named by token value.

The idea is that the user doesn't request any new tokens at all, you supply them with a fixed token that is valid for two years and they use that one all the time. That simplifies the life of the client as well since there is one request less to worry about.

Would that work in your scenario?

(By the way, letting unauthorized users upload whatever to FME Server is a massive security issue, especially if the server is visible to the world)


lazarlubomir
Contributor
Forum|alt.badge.img+10
  • Author
  • Contributor
  • September 27, 2019
david_r wrote:

The idea is that the user doesn't request any new tokens at all, you supply them with a fixed token that is valid for two years and they use that one all the time. That simplifies the life of the client as well since there is one request less to worry about.

Would that work in your scenario?

(By the way, letting unauthorized users upload whatever to FME Server is a massive security issue, especially if the server is visible to the world)

I dont think so, because I need to get token value to differentiate job results in export path according to token value. The server is not visible to the world, it is internal.


itay
Supporter
Forum|alt.badge.img+17
  • Supporter
  • September 27, 2019

Any chance you are using FME Server 2019? then you could use Server Apps.


Forum|alt.badge.img+2
  • Best Answer
  • October 3, 2019

Hi @lazarlubomir,

Since we were able to come to a resolution through a case I just wanted to share our findings here as well in case anyone else is looking for answers on this.

The main issue you were having is that you needed the Token to change everytime a request was submitted as you were using this token as a unique ID to name files/folders in your workflows as well. However this became a problem when you introduced parallel processing of requests because once a new ID was generated, any requests still needing to be processed with the old Token failed with an authentication error.

This is because in FME 2018.1 and older users are only eligible to have one session token at a time. Therefore in order to overcome this there were two options:

1. Give the guest account permissions to the repository containing the processing workspaces, this will remove the requirement for authorization via a token and the the workspace and data download requests will be able to run with unauthenticated access, but you can still generate the tokens to be used for file names (https://docs.safe.com/fme/html/FME_Server_Documentation/AdminGuide/Configuring-Authentication-for-Security-Resources.htm)

 

2. Generating a single token to be used for all requests that has a long expiry date and then using another method to name your files, a timestamp or UUID perhaps.

Alternatively in 2019+ the Token Management service was completely redone and now supports multiple valid session tokens created by a single user, meaning you could continue generating a new token for each series of requests and have these running in parallel.


lazarlubomir
Contributor
Forum|alt.badge.img+10
  • Author
  • Contributor
  • November 29, 2019
hollyatsafe wrote:

Hi @lazarlubomir,

Since we were able to come to a resolution through a case I just wanted to share our findings here as well in case anyone else is looking for answers on this.

The main issue you were having is that you needed the Token to change everytime a request was submitted as you were using this token as a unique ID to name files/folders in your workflows as well. However this became a problem when you introduced parallel processing of requests because once a new ID was generated, any requests still needing to be processed with the old Token failed with an authentication error.

This is because in FME 2018.1 and older users are only eligible to have one session token at a time. Therefore in order to overcome this there were two options:

1. Give the guest account permissions to the repository containing the processing workspaces, this will remove the requirement for authorization via a token and the the workspace and data download requests will be able to run with unauthenticated access, but you can still generate the tokens to be used for file names (https://docs.safe.com/fme/html/FME_Server_Documentation/AdminGuide/Configuring-Authentication-for-Security-Resources.htm)

 

2. Generating a single token to be used for all requests that has a long expiry date and then using another method to name your files, a timestamp or UUID perhaps.

Alternatively in 2019+ the Token Management service was completely redone and now supports multiple valid session tokens created by a single user, meaning you could continue generating a new token for each series of requests and have these running in parallel.

@hollyatsafe, thank You so much! Problem was in version 2018 of FME Server, so we had to upgrade to 2019 version.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings