Skip to main content
  • EN

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.

 

I have not tested it, but try accessing the server parameter FME_SECURITY_USER in your workspace, e.g. using a ParameterFetcher.
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 :-/

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.

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

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.

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.

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.

 

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.

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


Community Stats

30,352
Posts
115,344
Replies
38,087
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.