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
Why not simply create a user token with a maximum validity and use that?
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,
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)
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.
Any chance you are using FME Server 2019? then you could use Server Apps.
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.
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.