• EN
Question

FME Server 2019 vs 2018 Generating Tokens within expiration period

  • 16 October 2019
  • 4 replies
  • 3 views
krien
Rank
Badge +10

Hi,

Managing Tokens has changed in FME Server 2019 vs 2018 and I noticed the url for generating a Token with an expiration of 3 days without an update does not deliver the same token in 2019 in contrast to version 2018.

The url used has the format:

https://<fmeserver>/fmetoken/generate.json?user={{FMEUSER}}&password={{FMEPW}}&expiration=3&timeunit=day&update=false

and creates a new token (with a new 3 days expiration) every time in FME Server 2019 in contrast to 2018 where is returns the same token within the expiration period.

I’ve searched for some kind of equivalent url, but haven’t found it yet.

Is it still possible to get the same token during the expiration period in 2019 and what (service( url should I use?

Kind regards,

 

Krien Guijt

4 replies

H
Badge +2

In 2018 every user could only have one token, and this token would be assigned all of that users permissions, therefore using the generate token service, the only choice was to update or overwrite the existing token.

Instead in 2019 you have the ability to create multiple tokens per user and define permissions on an individual token basis for use with different applications/services. Therefore in order to update and existing token you will need to explicitly identify that token in the request, this can be done using the FME Server Rest API.

In FME Server if you view the Token Management page you'll see that using the https://<fmeserver>/fmetoken/generate URL generates a Session Token, session tokens will be assigned all the permissions that the User who created them has, these should be short-lived and really just be used by FME Server and for testing purposes. Instead for tokens being used by other applications you should be using API Tokens as their permissions can be restricted and tailored for specific use.

To create the API Token, this can be done either via the Web UI or through the Rest API POST /tokens endpoint (https://docs.safe.com/fme/html/FME_REST/apidoc/v3/index.html#!/tokens/createForm_post_1).

Every Token, API or Session, has a unique name, so once created you can use the PUT /tokens/<user>/<name> endpoint to update the existing Token (https://docs.safe.com/fme/html/FME_REST/apidoc/v3/index.html#!/tokens/updateForm_put_4).

 

 

krien
Rank
Badge +10

In 2018 every user could only have one token, and this token would be assigned all of that users permissions, therefore using the generate token service, the only choice was to update or overwrite the existing token.

Instead in 2019 you have the ability to create multiple tokens per user and define permissions on an individual token basis for use with different applications/services. Therefore in order to update and existing token you will need to explicitly identify that token in the request, this can be done using the FME Server Rest API.

In FME Server if you view the Token Management page you'll see that using the https://<fmeserver>/fmetoken/generate URL generates a Session Token, session tokens will be assigned all the permissions that the User who created them has, these should be short-lived and really just be used by FME Server and for testing purposes. Instead for tokens being used by other applications you should be using API Tokens as their permissions can be restricted and tailored for specific use.

To create the API Token, this can be done either via the Web UI or through the Rest API POST /tokens endpoint (https://docs.safe.com/fme/html/FME_REST/apidoc/v3/index.html#!/tokens/createForm_post_1).

Every Token, API or Session, has a unique name, so once created you can use the PUT /tokens/<user>/<name> endpoint to update the existing Token (https://docs.safe.com/fme/html/FME_REST/apidoc/v3/index.html#!/tokens/updateForm_put_4).

 

 

Hi @hollyatsafe,

Great explanation, quite clear. Thank you.

I made a few screenshots of the Generate Token differences between 2018 and 2019:

FME Server 2018 WebInterface Manage Token:

 

 

FMEServer 20128 Browser url returns same token:

 

FMEServer 2019:

 

And the link to the FME Server-Admin 2019 Token Management:

https://s3.amazonaws.com/gitbook/Server-Admin-2019/ServerAdmin4FMEServerUserAdministration/4.07.TokenManagement.html

I still have a question about the Tokens, as far I can see, Session are only used per user and per session in the FME Server Web Interface login and don't have other functionality, right?

In the Session Tokens list I see the Web Application Login, the FME Rest API (created from the Post /Tokens Try it out! in https://<fmeserver>/fmerest/apidoc/v3/#!/tokens/createJson_post_2 ) and Token Service Login created by https://<fmeserver>/fmetoken/generate.json?user=<user>&password=<password> are there other possibilities?

So in the Session Tokens you can just manage (Enable, Disable and Remove) the tokens in the list and the names in the list do not contain the token code, right?

Tanks again for explaining this new functionality.

Kind regards,

 

Krien Guijt

 

H
Badge +2

Hi @hollyatsafe,

Great explanation, quite clear. Thank you.

I made a few screenshots of the Generate Token differences between 2018 and 2019:

FME Server 2018 WebInterface Manage Token:

 

 

FMEServer 20128 Browser url returns same token:

 

FMEServer 2019:

 

And the link to the FME Server-Admin 2019 Token Management:

https://s3.amazonaws.com/gitbook/Server-Admin-2019/ServerAdmin4FMEServerUserAdministration/4.07.TokenManagement.html

I still have a question about the Tokens, as far I can see, Session are only used per user and per session in the FME Server Web Interface login and don't have other functionality, right?

In the Session Tokens list I see the Web Application Login, the FME Rest API (created from the Post /Tokens Try it out! in https://<fmeserver>/fmerest/apidoc/v3/#!/tokens/createJson_post_2 ) and Token Service Login created by https://<fmeserver>/fmetoken/generate.json?user=<user>&password=<password> are there other possibilities?

So in the Session Tokens you can just manage (Enable, Disable and Remove) the tokens in the list and the names in the list do not contain the token code, right?

Tanks again for explaining this new functionality.

Kind regards,

 

Krien Guijt

 

Hi @krien,

Yes, I would recommend Session Token values are only used per User and currently include:

  • Web Application Login or Web Application SSO Login - created when you log in through the FME Server Web UI and will be valid for the duration of that login session.
  • Token Service Login - created using fmetoken/generate endpoint, unless otherwise specified default expiry time is 5 minutes
  • FME Rest API - created when you 'get token' from FME Server REST API V3 and will expire after 1 hour.

It is possible this list may expand in future but the key takeaway is these token types should not be used externally.

You're correct that session Tokens can only be enabled/disabled and removed, on the other hand API Tokens can be managed through the FME Server Web UI by their owner, and other than being enabled/disabled/removed you also have the ability to modify the description, expiration date and have control over given permissions therefore these are designed to be used with specific applications.

krien
Rank
Badge +10

In 2018 every user could only have one token, and this token would be assigned all of that users permissions, therefore using the generate token service, the only choice was to update or overwrite the existing token.

Instead in 2019 you have the ability to create multiple tokens per user and define permissions on an individual token basis for use with different applications/services. Therefore in order to update and existing token you will need to explicitly identify that token in the request, this can be done using the FME Server Rest API.

In FME Server if you view the Token Management page you'll see that using the https://<fmeserver>/fmetoken/generate URL generates a Session Token, session tokens will be assigned all the permissions that the User who created them has, these should be short-lived and really just be used by FME Server and for testing purposes. Instead for tokens being used by other applications you should be using API Tokens as their permissions can be restricted and tailored for specific use.

To create the API Token, this can be done either via the Web UI or through the Rest API POST /tokens endpoint (https://docs.safe.com/fme/html/FME_REST/apidoc/v3/index.html#!/tokens/createForm_post_1).

Every Token, API or Session, has a unique name, so once created you can use the PUT /tokens/<user>/<name> endpoint to update the existing Token (https://docs.safe.com/fme/html/FME_REST/apidoc/v3/index.html#!/tokens/updateForm_put_4).

 

 

Hi @hollyatsafe,

Tnx again for your clear explanation.

While this stuff is not my daily business, it can be quite confusing sometimes so I'll dive deeper in it and share this with my colleagues.

Kind regards,

 

Krien Guijt

 

Reply


Community Stats

28,867
Posts
109,983
Replies
36,671
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.