Skip to main content
Solved

Get a user ID while running a Server App

I
Forum|alt.badge.img

Hi Everyone,

I have created a Server App (as admin) and gave an active directory account a right to run it (please, see attached)

Then, using app's url I log in as myself (dshatilov) and run the app. I thought it would run the job (the workspace) as dshatilov, but yet it runs it as admin. Is there a way to fix it?

 

What I am trying to achieve is to be able to run a server app as an active directory user and automatically extract user's name, so I could send the results back to a user without asking him or her to type in an email address.

When I log in as myself to the FME server and run the workbench from there, it runs it as dshatilov and sends the results back to my address, but when I run the server app, it doesn't.

 

Best answer by hollyatsafe

Hi @involver,

The FME_SECURITY_USER is defined as “FME Server user that runs the workspace.” In the context of Server Apps, this is always going to be the App Owner, as Server Apps run under an API token that belongs to that specific user. This is something that was implemented before Authenticated Apps were introduced.

We have seen a couple of enhancement requests asking for support in retrieving the username that logged in to run the app, I have added this Community Post to the internal issue (FMESERVER-15114) tracking this, so that you may be notified if this is added.

At the moment you will have to include a published parameter asking for this information.

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

9 replies

david_r
Celebrity
  • david_rCelebrity
  • July 3, 2020
I have not tested it, but try accessing the server parameter FME_SECURITY_USER in your workspace, e.g. using a ParameterFetcher.
I
Forum|alt.badge.img
  • involver
  • Author
  • July 5, 2020
david_r wrote:
I have not tested it, but try accessing the server parameter FME_SECURITY_USER in your workspace, e.g. using a ParameterFetcher.

Hi David,

Thanks for your reply.

Unfortunately, it still fetches the admin :-/

H
Forum|alt.badge.img+2
  • hollyatsafe
  • Best Answer
  • July 8, 2020

Hi @involver,

The FME_SECURITY_USER is defined as “FME Server user that runs the workspace.” In the context of Server Apps, this is always going to be the App Owner, as Server Apps run under an API token that belongs to that specific user. This is something that was implemented before Authenticated Apps were introduced.

We have seen a couple of enhancement requests asking for support in retrieving the username that logged in to run the app, I have added this Community Post to the internal issue (FMESERVER-15114) tracking this, so that you may be notified if this is added.

At the moment you will have to include a published parameter asking for this information.

sigtill
Supporter
Forum|alt.badge.img+24
  • sigtillSupporter
  • Supporter
  • September 26, 2020

Adding an "FME_LOGGEDIN_USER" Would be great to keep track on who runs the workspace.

The real SigTill
dms2
Contributor
Forum|alt.badge.img+11
  • dms2Contributor
  • Contributor
  • October 27, 2020
hollyatsafe wrote:

Hi @involver,

The FME_SECURITY_USER is defined as “FME Server user that runs the workspace.” In the context of Server Apps, this is always going to be the App Owner, as Server Apps run under an API token that belongs to that specific user. This is something that was implemented before Authenticated Apps were introduced.

We have seen a couple of enhancement requests asking for support in retrieving the username that logged in to run the app, I have added this Community Post to the internal issue (FMESERVER-15114) tracking this, so that you may be notified if this is added.

At the moment you will have to include a published parameter asking for this information.

We are very much interested in this too.

Server Apps are going to save us a lot of time but this is an important downside.

H
Forum|alt.badge.img+2
dms2 wrote:

We are very much interested in this too.

Server Apps are going to save us a lot of time but this is an important downside.

Hi @dms2​ ,

I've checked in on the internal enhancement request and currently there is no work going into this. I realised there isn't a community idea - perhaps you can post one. This will help our product owner better understand the demand for this feature and help him prioritise any future work for this.

dms2
Contributor
Forum|alt.badge.img+11
  • dms2Contributor
  • Contributor
  • October 30, 2020
dms2 wrote:

We are very much interested in this too.

Server Apps are going to save us a lot of time but this is an important downside.

You're right. Done!

@involver​ and @Sigbjørn Herstad​ here you have the link to the community idea if you want to vote for this.

 

bjarne
Contributor
Forum|alt.badge.img+5
  • bjarneContributor
  • Contributor
  • November 5, 2020
hollyatsafe wrote:

Hi @involver,

The FME_SECURITY_USER is defined as “FME Server user that runs the workspace.” In the context of Server Apps, this is always going to be the App Owner, as Server Apps run under an API token that belongs to that specific user. This is something that was implemented before Authenticated Apps were introduced.

We have seen a couple of enhancement requests asking for support in retrieving the username that logged in to run the app, I have added this Community Post to the internal issue (FMESERVER-15114) tracking this, so that you may be notified if this is added.

At the moment you will have to include a published parameter asking for this information.

In my opinion this problem should be treated as a bug.

dbaldacchino1
Enthusiast
Forum|alt.badge.img+13
sigtill wrote:

Adding an "FME_LOGGEDIN_USER" Would be great to keep track on who runs the workspace.

Very much agree. I have run into this limitation quite a few times. A current scenario we are running into is that we want to create API integrations with services such as Office 365 (ex: Outlook) that we could pass user data to the workspace so it can send emails to the user or set up calendar appointments etc. Without this, we'll have to provide a secondary input, which then sort of defeats the purpose of a login in the first place. This makes it risky as then anyone can impresonate anyone else and supply someone else's "username" or email just for the sake of passing data to the workspace.

Reply


Helpful Members This Week

Community Stats

31,328
Posts
118,850
Replies
38,945
Members

Latest FME

Terms & ConditionsCookie settings

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
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.